SQLServer2000之日志传送功能-描述（1）

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

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

    当线上数据库停摆时(可能是计划内维护工作，或是预期外的状况)，如果还有备援服务器上的数据库可供存取，您可能会比较安心一点。一个设计良好的日志传送系统(将数据库交易日志文件从主要服务器传送到备援服务器)即可给予您这样的自信心。内建于 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,
       @aclearcase/" target="_blank" >ccess_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)。该工作激活之后，交易日志备份文件就会开始出现在新主要服务器。您需要这些档案去重新设定将日志传送回新次要服务器。