SQL Server 2000之日志传送功能 - 描述

SQL Server 2000之日志传送功能 - 描述

角色变更、角色互换、以及监控服务器所在位置

    当线上数据库停摆时(可能是计划内维护工作，或是预期外的状况)，如果还有备援服务器上的数据库可供存取，您可能会比较安心一点。一个设计良好的日志传送系统(将数据库交易日志文件从主要服务器传送到备援服务器)即可给予您这样的自信心。内建于 SQL Serve 2000 企业板与开发版的 Enterprise Manager 工具程序即支持日志传送功能。

角色变更

    将日志从主要服务器传送到次要服务器之后，您可在必要时以次要服务器置换掉主要服务器。如果主要服务器发生问题，或是计划性停摆(例如升级硬件或安装修正程序)，线上数据库就必须停止服务一段期间。此时您可以变更次要服务器上数据库之角色，让它取代主要服务器之后进而成为线上数据库。SQL Server 2000 线上手册(Books Online，BOL)将此项操作称为日志传送角色变更(log shipping role change)。在日志传送过程里，次要服务器需设定在无法复原(nonrecovered)状态，因此交易日志才能从主要服务器回存到次要服务器(一但您将数据库复原，就不能再回存交易记录)。变更角色时，您需将次要服务器的数据库予以复原，并标示其为新主要服务器数据库。您也可以将旧主要服务器数据库设定为新次要服务器数据库。如果旧主要服务器数据库并未损坏，那么就可以在新主要服务器与旧主要服务器(已变成新次要服务器)之间重新建置日志传送功能。这种切换方式我们称为角色互换(role reversal)。

    这些操作指引可修订为六个基本步骤，分别为： 1、转移与汇出登入帐号，2、降级(demote)主要服务器，3、升级(promote)次要服务器，4、通知监控服务器角色已变更，5、在次要服务器上解析登入帐号，6、以及连结数据库存取与权限。

    步骤 1: 转移与汇出登入帐号 首先，BOL 建议您建立一个SQL Server 2000 DTS封装(package)，用来将主要服务器的登入帐号转移到次要服务器，且执行各服务器间登入帐号SID之解析动作。转移登入帐号所用的 DTS Transfer Logins Task只能在 SQL Server 2000 DTS Designer内使用。您可在主要服务器上建立与储存 DTS 封装，然后呼叫 dtsrun.exe 设定该封装的执行方式 — 透过主要服务器 SQL Server Agent 的工作(job)。该封装执行时会将登入帐号从某服务器传送到另一服务器，但是它并不会解析其登入帐号的SID(在稍后步骤中会说明为何需解析登入帐号)。然而，为了在稍后能顺利解析登入帐号，您必须先建立一个档案，其内包含主要服务器 syslogins 资料表的汇出资料。

    汇出登入帐号到次要服务器时，BOL建议您建立一个两阶段的SQL Server Agent工作：使用bcp汇出，以及复制登入帐号。在第一个步骤，您将使用原始模式的bcp将登入帐号汇出至某个档案。而在第二个步骤里，您必须将登入帐号复制到次要服务器的某个档案，以便稍后进行角色变更时可用来解析登入帐号。在步骤5您将使用 sp_resolve_logins 预存程序去解析次要服务器上登入帐号的SID。该工作建立完成后，就可以定期地执行(例如每晚执行一次)。如此一来次要服务器上将随时保留最新的登入帐号汇出文件，以便进行日志传送角色变更。

    步骤 2: 降级主要服务器 为了让主要服务器不再是日志传送系统的资料来源，您必须将它”降级”。您可以降级主要服务器的来源数据库，让它变成潜在的次要服务器。然后在主要服务器上执行sp_change_primary_role 预存程序，目的是移除原有日志传送功能。程序代码列表1显示该预存程序如何把 Pubscopy 日志传送数据库从读/写模式更改成只读备援模式，准备随时接受交易日志之备份资料。该预存程序经由数个步骤后会在日志传送计划内删除主要服务器数据库。传入的参数将告之预存程序需执行以下工作：备份最近一次的交易日志、结束数据库内所有使用者联机、将数据库设定在备援状态与多使用者存取层级。预存程序的回传代码将标示 BACKUP LOG 叙述句是否成功执行。

    程序代码列表1：将日志传送数据库从读/写模式降级成只读模式之预存程序。
USE master
GO
EXEC msdb.dbo.sp_change_primary_role
       @db_name = 'Pubscopy',
       @backup_log = 1,
       @terminate = 1,
       @final_state = 3,
       @access_level = 1

    步骤 3: 升级次要服务器 下一个步骤是把目前次要服务器升级成复原状态(recovered state)，这样它才能取代原先的线上数据库，且变成潜在日志传送主要服务器数据库。在次要服务器上，如果您已确认无任何使用者继续存取数据库，就可以执行 sp_change_secondary_role 预存程序，如程序代码列表2所示：

    程序代码列表 2：将次要服务器数据库升级成主要服务器数据库之预存程序。
USE master
GO
EXEC msdb.dbo.sp_change_secondary_role
       @db_name = 'Pubscopy',
       @do_load = 1,
       @force_load = 1,
       @final_state = 1,
       @access_level = 1,
       @terminate = 1,
       @keep_replication = 0,
       @stopat = null

    这些参数将促使该预存程序尝试将所有剩余的交易日志文件从原先主要服务器复制到次要服务器，并将这些日志文件加载次要服务器数据库。参数 @do_load=1 会进行最近一次备份，并加载所有交易日志文件；参数 @force_load=1 是在执行 sqlmaint.exe 时指定尚未文件化的 Forceload 选项；参数 @final_state=1 将新主要服务器数据库设定为复原模式；参数 @access_level 将存取方式设回先前多使用者状态。参数 @terminate=1 则促使该预存程序中断所有使用者的数据库存取动作 — 方式是执行 ALTER DATABASE 配合 IMMEDIATE 选项。然而，如果执行此预存程序时，您自己的 Enterprise Manager 与数据库间联机处于开启状态，ALTER DATABASE 动作将会失败。所以您必须以手动方式确认是否已将所有数据库联机予以中断。最后，如果该数据库被设定为数据库复写(replication)之出版者数据库(publisher)，那么 @keep_replication=0 参数将依旧维持服务器上所有复写设定。

    假如您曾选择让次要服务器成为未来潜在的主要服务器，则数据库维护计划会在次要服务器上建置一个交易日志备份工作(SQL Server Agent 的transaction-log backup job)。该工作激活之后，交易日志备份文件就会开始出现在新主要服务器。您需要这些档案去重新设定将日志传送回新次要服务器。

    Step 4: 通知监控服务器角色已变更 SQL Server 2000 的日志传送会在监控服务器上安装监控工具程序；最好是在第三台服务器。为了通知监控服务器日志传送的角色已经过变更，您必须在监控服务器上执行 sp_change_monitor_role 预存程序，如程序代码列表3所示。尽管名称内含有 change 字眼，但它并不会变更监控服务器的角色。相反地，此预存程序会变更主要/次要服务器内档案分享所参照(reference)的位置。意思是说：监控服务器 log_shipping_secondaries 资料表内原先参照旧次要服务器的资料会被删除。而在 log_shipping_primaries 资料表内则是将旧主要服务器名称更改为新主要服务器名称。此预存程序并不会将资料新增到 log_shipping_secondaries 资料表，因为新的配对服务器目前尚未建置。
 
       程序代码列表 3： 将角色互换结果通知监控服务器之预存程序。
USE master
GO
EXEC msdb.dbo.sp_change_monitor_role
      @primary_server = 'oahu/sql2k_1' ,
      @secondary_server = 'oahu/sql2k_2',
      @database = 'Pubscopy',
      @new_source = 'oahu/sql2k_2'
 
       步骤 5: 在次要服务器上解析登入帐号 您必须先在新主要服务器上解析旧主要服务器登入帐号，使用者才可以存取新主要服务器；方式是使用步骤1所汇出之登入帐号档案。此汇出档案可被 sp_resolve_logins 预存程序所读取，然后解析各服务器间 SID 的差异。举例来说，程序代码列表4示范如何在新复原的 Pubscopy 数据库上执行 sp_resolve_logins 预存程序，去解析原来的登入帐号。BOL文章曾教导您必须在目的数据库内才能执行该预存程序。事实上，sp_resolve_logins 使用了非完整式参照(unqualified reference)指向 syslogins 视观表，所以您必须在 master 数据库内才能执行此预存程序！
 
        程序代码列表4： 在次要服务器上解析登入帐号的预存程序。
USE master
GO
EXEC sp_resolve_logins
      @dest_db = 'Pubscopy',
      @dest_path = 'd:/',
      @filename = 'syslogins.dat'
 
        步骤 6: 连结数据库存取与权限 BOL 对于角色变更的相关讨论仅止于步骤5，但是它忽略一个重要步骤：在 "数据库存取权限" 与 "转移后登入帐号" 之间进行协调动作。为了在新主要服务器内线上数据库，将移转后已解析的登入帐号连结至相对应的数据库使用者及其权限，您必须执行针对每个登入帐号执行一次 sp_change_users_login 预存程序。
 
USE pubscopy
GO
EXEC sp_change_users_login 'Update_One', 'UserName', 'LoginName'
 
        执行该预存程序可确保 SQL Server 登入帐号能够正确地连结相对应的数据库使用者名称。
 
        到此为止，您已经成功地将次要服务器升级为新的角色，而旧主要服务器也早已变成次要服务器。然而，您仍然尚未建置新的日志传送关系。您完成的只是角色变更，而不是角色互换。
 
角色互换

        为了达成完整的日志传送角色互换，您只需在新主要服务器与新次要服务器之间重新设定一次日志传送即可。因为新主要服务器已内含崭新的数据库维护计划，您将会倾向在维护计划内直接加入新次要服务器，做为目的服务器。然而经过多次尝试之后，我发现新主要服务器的 "交易日志备份工作" 总是会失败，并且日志也不会从新主要服务器传送到新次要服务器。
 
        所以，您需要另外一种方法。您在执行过日志传送角色变更的预存程序，以及先前我详细说明的步骤后，就可以直接达成完整的角色互换 - 在新主要服务器与新次要服务器之间建置一份新的日志传送计划。为了建置该计划，您需遵循下列步骤：
1.        在新主要服务器的数据库维护计划内移除日志传送功能。
2.        在主要服务器上删除数据库维护计划。
3.        在次要服务器上删除数据库维护计划。
4.        维持所有交易日志文件。
5.        在新主要服务器上建立一个新的数据库维护计划，指定新次要服务器所在、目的数据库位置、以及交易日志文件之适当存放位置，如同我在 Part 1所介绍的内容。
6.        重新开始新主要服务器的所有活动。
 
        在您成功设定角色互换且建置新日志传送配对服务器之后，Enterprise Manager 的日志传送监视器可能会告知您新次要服务器数据库并未与新主要服务器数据库取得同步(out of sync)。如果 "最近一次加载的交易日志" 与 "最近一次备份的交易日志" 之间的时间差超过了 out-of-sync 设定值，您就会收到此报告。直到最近一次的备份资料被加载之后，日志传送监视器就会回到平常无错误状态。
 
日志传送监视器所在位置

      Microsoft 强烈建议将日志传送监视器置放于独立服务器上。如此一来，无论主要服务器或是次要服务器执行工作失败时，该监视器都会送出警示(alert)。如果监视器位于主要或次要服务器其中之一，报告结果将取决于监视器所在服务器。如果监视器所在服务器因故停摆，它将无法继续回报可能的错误情况。所以，要让监视器独立回报日志传送系统内主要或次要服务器上可能发生的问题，给予监视器一台独立服务器是较佳的实作方式。此外，也可以使用这台独立的监控服务器去监控其它日志传送配对服务器。
 
        如果没有其它服务器可安装监控程序，而需要放在主要或次要服务器其中之一。究竟应该把日志传送监视器放在哪台服务器呢？因为重点是想侦测主要服务器上可能发生的日志传送问题，所以放在次要服务器比较妥当。如果将日志传送监视器放在主要服务器上，当主要服务器停摆时，您就无法使用该监视器，监视器也无法在日志传送发生问题时送出警示。所以呢，如果只有两台服务器可使用，次要服务器为置放日志传送监视器较佳的位置。某些时候，为避免灾难发生时影响次要服务器，必须将交易日志从某一实体位置传送到另一个地方(也许有一段距离)。在此情况下，日志传送监视器最好放在其它地方的独立服务器，让灾难发生时不至于影响主要与次要服务器。

转摘《DigJim的专栏》——实在精典，希望更多的人学习，资源共享