SQL Server 2000之日志传送功能（2）
类别: MSSQL教程 
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)。如果监视器位于主要或次要服务器其中之一，报告结果将取决于监视器所在服务器。如果监视器所在服务器因故停摆，它将无法继续回报可能的错误情况。所以，要让监视器独立回报日志传送系统内主要或次要服务器上可能发生的问题，给予监视器一台独立服务器是较佳的实作方式。此外，也可以使用这台独立的监控服务器去监控其它日志传送配对服务器。
如果没有其它服务器可安装监控程序，而需要放在主要或次要服务器其中之一。究竟应该把日志传送监视器放在哪台服务器呢？因为重点是想侦测主要服务器上可能发生的日志传送问题，所以放在次要服务器比较妥当。如果将日志传送监视器放在主要服务器上，当主要服务器停摆时，您就无法使用该监视器，监视器也无法在日志传送发生问题时送出警示。所以呢，如果只有两台服务器可使用，次要服务器为置放日志传送监视器较佳的位置。某些时候，为避免灾难发生时影响次要服务器，必须将交易日志从某一实体位置传送到另一个地方(也许有一段距离)。在此情况下，日志传送监视器最好放在其它地方的独立服务器，让灾难发生时不至于影响主要与次要服务器。
程序代码列表 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)。如果监视器位于主要或次要服务器其中之一，报告结果将取决于监视器所在服务器。如果监视器所在服务器因故停摆，它将无法继续回报可能的错误情况。所以，要让监视器独立回报日志传送系统内主要或次要服务器上可能发生的问题，给予监视器一台独立服务器是较佳的实作方式。此外，也可以使用这台独立的监控服务器去监控其它日志传送配对服务器。
如果没有其它服务器可安装监控程序，而需要放在主要或次要服务器其中之一。究竟应该把日志传送监视器放在哪台服务器呢？因为重点是想侦测主要服务器上可能发生的日志传送问题，所以放在次要服务器比较妥当。如果将日志传送监视器放在主要服务器上，当主要服务器停摆时，您就无法使用该监视器，监视器也无法在日志传送发生问题时送出警示。所以呢，如果只有两台服务器可使用，次要服务器为置放日志传送监视器较佳的位置。某些时候，为避免灾难发生时影响次要服务器，必须将交易日志从某一实体位置传送到另一个地方(也许有一段距离)。在此情况下，日志传送监视器最好放在其它地方的独立服务器，让灾难发生时不至于影响主要与次要服务器。
