---

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. 在新主要
服务器
的数据库维护计划内移除日志传送功能。
[color=#FFFFFF'][/color]

2. 在主要
服务器
上删除数据库维护计划。
3. 在次要
服务器
上删除数据库维护计划。
4. 维持所有交易日志文件。
5. 在新主要
服务器
上建立一个新的数据库维护计划，指定新次要
服务器
所在、目的数据库位置、以及交易日志文件之适当存放位置，如同我在 Part 1所介绍的内容。
6. 重新开始新主要
服务器
的所有活动。

在您成功设定角色互换且建置新日志传送配对
服务器
之后，Enterprise Manager 的日志传送监视器可能会告知您新次要
服务器
数据库并未与新主要
服务器
数据库取得同步(out of sync)。如果 "最近一次加载的交易日志" 与 "最近一次备份的交易日志" 之间的时间差超过了 out-of-sync 设定值，您就会收到此报告。直到最近一次的备份资料被加载之后，日志传送监视器就会回到平常无错误状态。

日志传送监视器所在位置
Microsoft 强烈建议将日志传送监视器置放于独立
服务器
上。如此一来，无论主要
服务器
或是次要
服务器
执行工作失败时，该监视器都会送出警示(alert)。如果监视器位于主要或次要
服务器
其中之一，报告结果将取决于监视器所在
服务器
。如果监视器所在
服务器
因故停摆，它将无法继续回报可能的错误情况。所以，要让监视器独立回报日志传送系统内主要或次要
服务器
上可能发生的问题，给予监视器一台独立
服务器
是较佳的实作方式。此外，也可以使用这台独立的监控
服务器
去监控其它日志传送配对
服务器
。

如果没有其它
服务器
可安装监控程序，而需要放在主要或次要
服务器
其中之一。究竟应该把日志传送监视器放在哪台
服务器
呢？因为重点是想侦测主要
服务器
上可能发生的日志传送问题，所以放在次要
服务器
比较妥当。如果将日志传送监视器放在主要
服务器
上，当主要
服务器
停摆时，您就无法使用该监视器，监视器也无法在日志传送发生问题时送出警示。所以呢，如果只有两台
服务器
可使用，次要
服务器
为置放日志传送监视器较佳的位置。某些时候，为避免灾难发生时影响次要
服务器
，必须将交易日志从某一实体位置传送到另一个地方(也许有一段距离)。在此情况下，日志传送监视器最好放在其它地方的独立
服务器
，让灾难发生时不至于影响主要与次要
服务器
。
[color=#FFFFFF'][/color]