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,
@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)。如果监视器位于主要或次要服务器其中之一，报告结果将取决于监视器所在服务器。如果监视器所在服务器因故停摆，它将无法继续回报可能的错误情况。所以，要让监视器独立回报日志传送系统内主要或次要服务器上可能发生的问题，给予监视器一台独立服务器是较佳的实作方式。此外，也可以使用这台独立的监控服务器去监控其它日志传送配对服务器。
如果没有其它服务器可安装监控程序，而需要放在主要或次要服务器其中之一。究竟应该把日志传送监视器放在哪台服务器呢？因为重点是想侦测主要服务器上可能发生的日志传送问题，所以放在次要服务器比较妥当。如果将日志传送监视器放在主要服务器上，当主要服务器停摆时，您就无法使用该监视器，监视器也无法在日志传送发生问题时送出警示。所以呢，如果只有两台服务器可使用，次要服务器为置放日志传送监视器较佳的位置。某些时候，为避免灾难发生时影响次要服务器，必须将交易日志从某一实体位置传送到另一个地方(也许有一段距离)。在此情况下，日志传送监视器最好放在其它地方的独立服务器，让灾难发生时不至于影响主要与次要服务器。
日志传送功能可自动复制数据库的交易日志文件，并回存到备援服务器 (standby server) 的另外一个数据库。因此可大幅提高SQL Server数据库之可用性。因为备援数据库完整地接收来源数据库的异动情况，所以它就是一份来源数据库的复本 - 差别仅在于资料复制与加载过程所产生的时间差。然而，当主要服务器停摆时，您就可以将备援服务器更改为新的主要服务器。如果原来的主要服务器可重新上线使用，那么您可以将其设定为新的备援服务器 - 事实上就是对调两台服务器的角色。
在SQL Server 2000企业版或开发版之中，Microsoft在Enterprise Manager内提供了一项日志传送(Log Shipping)的功能 - 为数据库维护计划精灵的其中一部份。在使用之前的SQL Server时，您需要自行建立日志传送系统。
设定日志传送
主要服务器(primary server) 即是实际处理资料的正式服务器；此服务器内拥有来源数据库。次要服务器(secondary server)上存放目的数据库，用来复制与回存来源数据库的交易日志文件。监控服务器(monitor server)用来监控主要服务器与次要服务器。与SQL Server 7.0不同的是(SQL Server 7.0是在次要服务器上监控日志传送动作)，SQL Server 2000使用Enterprise Manager的日志传送监控工具来监控每一组传送中的日志资料。Microsoft建议您在另外一台监控用服务器安装这个工具程序。
您可以利用Enterprise Manager的数据库维护计划精灵设定SQL Server 2000的日志传送。但是在您激活精灵之前，您必须先进行某些准备工作。一开始请先遵循下列步骤：
1.决定一组要设定日志传送的服务器(即日志传送过程之中，主要服务器与次要服务器为何)。
2. 选择一台监控服务器。最好不同于主要服务器或次要服务器。
3. 设定所有服务器之安全性。您用来设定日志传送的Windows帐号必须拥有所有服务器上SQL Server系统管理者(sa)的权限。
4. 在主要/次要服务器上建立分享资料夹。首先，将来源数据库交易日志文件所在的目录设定为分享目录。接着在次要服务器上，将您打算回存交易日志文件的目录也分享出来。为了清楚辨别各分享目录，请在分享名称内注明服务器与数据库之名称。如果分享目录名称已存在，您可能需要从分享目录中删除或是搬移其它档案，特别是旧的日志备份文件。然后再将这些分享目录的权限开放给每一台服务器上SQL Agent所使用的Windows帐号。
5. 决定如何建立并初始化目的地数据库。您可以在日志传送设定过程就先建立与初始同步化目的地数据库，否则您必须手动进行初始数据库之回存动作。
6. 在Enterprise Manager注册此三台服务器(即主要、次要与监控服务器)。
在您完成这些准备动作时，您就可以准备激活数据库维护计划精灵来设定日志传送。您可以先检视日志传送过程的五个连续步骤，如图1所示：
图1：SQL Server 2000日志传送的设定步骤。
前两个为选择性(optional)步骤。如果您尚未同步化来源与目的数据库，则步骤1会为您先备份来源数据库，然后执行同步化动作。在步骤2时，精灵会将备份文件复制到次要服务器，并回存到目的地数据库。
精灵一定会执行其余三项步骤。在步骤3时，精灵将在主要服务器上建立一个SQL Agent工作(job)。此工作将会周期性地把交易日志文件内容备份到磁盘档案内。精灵也会在次要服务器上建立一个传送日志的数据库维护计划；此计画包含两个SQL Agent工作：一个是将交易日志文件复制到次要服务器(步骤4)，另一个则是将交易日志文件回存到目的数据库(步骤5)。这些步骤将建立一组日志传送服务器(互相有日志传送关系的两个数据库)。如果您想要额外提供容错功能或是设定一台报表服务器，那么您可以将主要服务器与另外一台次要服务器组合在一起，再设定一组日志传送配对服务器。
准备工作
1. 准备 Primary Server (以下为Ztao-1) 及 Secondary Server (以下为IntronTest)
2. 将要作 Log Shipping 的数据库(以下为IntronERP)之还原模型(Recovery Model)设定为完整(FULL)。
3. 将两台计算机的SQL Server服务账号加入Administrator群组
4. 建立Primary Server 备份Log的数据夹
a. 建立C:\Logfile，以存放Primary Server数据库Transaction Log的备份
b. 将C:\Logfile作数据分享，分享目录的权限开放给SQL Agent所使用的Windows帐号。
5. 建立 Secondary Server 还原的数据夹(在Secondary Server)
a. 建立C:\Shippedlog数据夹以存放从Primary Server传送过来的Transaction log 的备份
b. 建立 C:\Logfile数据夹，当角色交换后，可存放新Primary Server的数据库Transaction Log
c. 将C:\Logfile数据夹作资源共享，分享目录的权限开放给SQL Agent所使用的Windows帐号。
6. 在Primary Server中，新增 Secondary Server的注册信息
逐步设定
在Primary Server中，设定Standby Server及Log shipping
1、开启Enterprise Manager，由工具中点选数据库维护计划
2、欢迎画面：
3、选取数据库：勾选Log shipping
4、更新数据最佳化信息：维持预设，不用选择！
5、数据库完整性检查：维持预设，不用选择！
6、指定数据库备份计划：一般不用选择！
7、指定交易记录文件备份磁盘目录：储存备份文件的目录指向Primary Server上存放资料日志文件的目录位置！
8、指定交易记录共享：在此窗口中您必须指定主服务器上的分享目录名称。可以按下【…】按钮后浏览目录名称。
9、指定记录传送目的地：点选【Add】按钮后可开启『新增目的数据库』对话框
10、新增目的数据库：输入所有Secondary Server的相关信息
【伺服务器名称】下拉式选单会列出您在先前准备工作中曾利用Enterprise Manager所注册的Secondary Server名称。在【目录】文字字段里，请输入Secondary Server的目录名称，用以接收来源数据库交易日志文件复本；此名称为本地端路径名称，而不是分享目录名称。
有关数据库的加载状态，您有两种选项可以设定：不复原模式(No recovery mode)与待命模式(Standby mode)。所谓的『不复原模式』表示使用者将无法进行资料查询，唯一可执行的动作只有回存交易日志文件。而『待命模式』则是将数据库设定成只读状态；只要不是在回存数据库的时候，您都可以查询资料。窗口内还有一个【终止数据库中的使用者(建议选项)】选项，会在回存数据库或是回存交易日志文件时发生动作。在回存数据库或是交易日志文件时，『回存程序』将是数据库内唯一的使用者。所以，Microsoft建议您勾选此选项，否则其它使用者可能会影响回存动作的进行。
11、指定记录传送目的地：该设定完成。
12、初始化目的服务器：可以挑选最近一次的备份资料；或是建立一份新的备份资料。对大型数据库而言，使用既有的备份资料会比较有效率。然而，从那次备份之后的所有交易日志文件都必须存在于主要服务器上交易日志文件的分享目录之中，精灵才有办法复制与回存到次要服务器。如果数据库不是很大，那么让精灵产生新的备份将会比较简单。
13、记录传送排程：可以设定来源数据库上交易日志文件的备份频率；也可以设定次要服务器上SQL Agent工作 (由精灵建立的，用来复制与加载交易日志文件) 的频率。日志传送的频率可粗略设定为一分钟一次；但以大型数据库来说，五分钟一次是比较普遍的选择。
14、记录传送临界值：针对交易日志文件备份动作，以及复制与回存工作，设定合理的延迟时间。当超过临界时间时，日志传送监控程序对话框将会响应一个警示讯息。
15、指定记录传送监视服务器信息：这里可能会直接使用默认值，但是预设监控服务器是设定为主要服务器。一般来说，不会把主要或次要服务器当作监控服务器，这是因为如果其中一台服务器故障停摆时，将无法得知目前日志传送的状态为何。
16、产生报告：建议将报告存到你Log的目录下，或者专门存放有关Log Shipping的Log的目录下，方便出错时查找原因！
17、维护计划历程记录：在Secondary Server上也保存一份记录。
18、设定Log Shipping名字
19、按下【完成】吧！此时精灵会自动从主要服务器与次要服务器之间设定日志传送动作，并且在监控服务器上设定日志传送监控程序。
您可以使用数据库维护计划之【属性】对话盒来更改日志传送相关设定。在【交易记录文件备份】设定页提供的选项可更改日志传送过程中交易日志文件备份的组态。
【记录传送】设定页显示出您先前在维护计划内设定的日志传送配对服务器；如果您设定了其它组日志传送配对服务器，也会列在此处。本设定页也包含下列选项：新增目的数据库(用以建立新的日志传送配对服务器)、删除既有日志传送配对服务器、编辑目前的日志传送配对服务器之属性，以及移除整个日志传送功能。
当您在【记录传送】设定页之中点选【编辑】时，将开启【编辑目的数据库】对话盒。您可以在对话盒内【一般】设定页检视与修改次要服务器的交易日志文件之目录位置，以及未来做为主要服务器时分享目录之路径。【初始化】设定页则可让您更改复原模式，以及次要服务器上复制与回存之频率。【临界值】页可以设定日志传送之临界周期。
在【超出同步临界值】项目可设定：当日志传送监控程序产生警示讯息之前所能允许的最大时间间隔 (介于最近一次来源数据库交易日志文件备份以及最新的交易日志文件回存动作之间)。您也可以在日志传送监控程序之中设定此参数。【在入时间延迟】、【档案保留期限】以及【历程记录保留期限】则是与次要服务器相关的设定。
注：监控服务器在这些组态选项中扮演相当重要的角色。因为【记录传送】设定页的大部分信息取决于监控服务器，所以一但监控服务器停摆时，您将无法更改日志传送的组态设定值。在监控服务器执行SQL Server 2000 Profiler时，主要服务器会连到监控服务器，然后从日志传送资料表中取得既有的日志传送计划。因此，要改变日志传送计划的设定时，您必须确定在Enterprise Manager内可以连接到监控服务器。
检查与监控日志传送动作
SQL Server 2000的日志传送功能还提供了一项日志传送监控程序，可让您安装在另一台独立监控用服务器。
在SQL Server企业版与开发版的msdb数据库中共有七个关于日志传送的资料表：
log_shipping_plans
log_shipping_plan_databases
log_shipping_databases
log_shipping_plan_history
log_shipping_monitor
log_shipping_primaries
log_shipping_secondaries
上述每一个资料表都存在于主要、次要以及监控服务器上。各服务器也会使用某些资料表储存资料，视该服务器在日志传送系统的角色为何。
在主要服务器上检视日志传送动作 从Enterprise Manager 里，您可以登入主要服务器，并观察与监控日志传送动作。如果某个数据库已设定要进行日志传送，在数据库【内容】对话盒的【一般】页可得知该数据库的角色(来源数据库；或是目的数据库)，也可知道日志传送监控程序是位于那一台服务器上。您可以在Enterprise Manager内SQL Server Agent的【作业】节点，检视日志传送与交易日志文件备份工作所执行的状态与历史纪录。主要服务器只使用msdb数据库的两个日志传送资料表。在log_shipping_databases资料表中，SQL Server新增的每一笔资料将会把数据库维护计划ID以及日志传送来源数据库连结在一起。在log_shipping_monitor资料表中，SQL Server新增的每一笔资料包含了监控服务器的名称，以及登入数据库的方式。
在次要服务器上检视日志传送动作 日志传送计划存在于次要服务器。您可在次要服务器监控SQL Agent工作(复制交易日志文件到次要服务器，并回存至目的数据库)。 您也可检视目的数据库的属性对话盒，以决定该数据库在日志传送过程所扮演的角色。
在次要服务器上，SQL Server使用msdb数据库的四个日志传送资料表。当SQL Server建立一个日志传送计划之后，它会新增一笔资料到log_shipping_plan资料表，用以纪录：主要与次要服务器的名称、档案位置、复制与回存工作ID(来自于次要服务器之sysjobs系统资料表)。在log_shipping_plan_databases资料表，SQL Server会连结维护计划以及来源/目的数据库名称，而且储存最后一次进行档案复制与加载动作的相关信息。log_shipping_plan_history资料表则是将每次日志传送的复制与回存事件纪录下来，连同该工作是否成功的信息。SQL Server也会新增一笔资料在log_shipping_monitor资料表，用以参照监控服务器。
如果您勾选了【Allow database to assume primary role】复选框，您将在次要服务器上看到一个重要的额外项目：另一个数据库维护计划(与您先前所建立的维护计划名称相同)，但是并没有激活日志传送。您也会看到一个非作用中(disabled)的SQL Agent工作(备份该数据库的交易日志)。也许您会被这些项目所混淆。尽管它们的名字相同，但是此额外产生的维护计划却不同于当初所建立的那个。SQL Server保留第二个逆向维护计划是为了以后可能发生的主要/次要服务器角色对调动作所准备。
在监控服务器上检视日志传送动作 当您正确设定日志传送之后，SQL Server 会激活监控服务器上Enterprise Manager 的日志传送监控工具程序。此外，SQL Server会建立两个SQL Agent 警示工作(alert job)：一个用来执行工作，另一个处理out-of-sync情况。
使用监控工具程序的方式是，开启Enterprise Manager并连至监控服务器，展开【Management】节点，然后点选【记录传送监视器(Log Shipping Monitor)】。当您点选此工具程序时，其内会列出日志传送配对服务器的清单。您可在配对服务器上按下鼠标右键，检视其备份、复制与回存等工作的执行历史纪录。这些历史纪录十分有用，因为您从这里得到的错误讯息会比从次要服务器上(SQL Agent 复制与回存工作)得到的更为详尽。
如图所示：当您开启配对服务器之属性对话盒，并进入【Status】设定页时，您可检视此配对服务器执行备份与回存程序之状态。
其状态(Status)可以是Normal 或是Out-of-Sync。如果SQL Server Agent尚未复制或回存交易日志文件，对话盒内将会显示日志文件名为first_file_000000000000.trn。这并不是实际的文件名称，只不过是用来标示SQL Server Agent尚未处理任何档案而已。在【Status】设定页也会显示备份、复制以及加载(回存)等动作执行时所耗费的时间。此设定页之信息不会自动更新，所以您必须将此对话盒关闭后再开启，才能更新其资料。
SQL Server只使用msdb数据库内两个资料表来储存日志传送服务器之相关资料。SQL Server在这两个资料表中都给予一个ID做为连结，以及一个外来键(foreign key)。该外来键是设定在log_shipping_secondaries资料表上，并参照log_shipping_primaries资料表的primary_id字段(这两个是所有日志传送资料表中唯一具有外来键关系的资料表)。在log_shipping_primaries资料表内的每笔资料都包含日志传送的相关信息，例如：来源数据库名称、交易日志文件备份工作执行之状态，以及已规划的停摆信息(可避免不必要的警示讯息)。而log_shipping_secondaries 资料表之每笔资料关于目的数据库之信息；每个目的数据库附属于特定的日志传送来源数据库。这两个资料表互相连结的结果就是日志传送监控程序内所显示的配对服务器信息。
移除与重新组态日志传送功能
如果您想从数据库维护计划中移除日志传送功能，可参考下列方式：开启该计划的属性对话盒，选择【记录传送】设定页，然后点选【移出记录传送】。此动作将从次要服务器上移除SQL Server Agent的备份与回存工作，并清除日志传送资料表内的所有相关资料。此外，日志传送监控程序的相关信息也会一并被清除。然而此动作将会适当地保留主要服务器上SQL Server Agent的交易日志备份工作。只有在删除数据库维护计划时，该工作才会被移除。假如您想从监控服务器内移除掉日志传送监控程序，请用手动方式将log_shipping_primaries与log_shipping_secondaries这两个资料表(位于监控服务器的msdb数据库)的资料删除即可。
如果您在数据库维护计划内设定日志传送时，就已允许目的数据库可以做为新的日志传送来源数据库。当您删除主要服务器的维护计划时，次要服务器上仍然会保留其数据库维护计划，以及交易日志文件备份工作。删除这些项目的方式是将次要服务器上与日志传送相关的数据库维护计划直接删除。
SQL Server 2000之日志传送功能
可能發生的錯誤
一、残余数据
当您进行SQL Server 2000日志传送的实验时，也许偶而会中断设定过程。如果真是如此，那么某些资料仍然会存入每台服务器的日志传送资料表，并且影响到后续的日志传送设定动作。为了保证这些剩余资料都会被清除，请确实删除每台服务器msdb数据库内日志传送资料表之相关资料。
错误信息：
Error 14261: The specified primary_server_name.primary_database_name ('N') already exists.
Error 14426: A log shipping monitor is already defined (...)
处理方法：
必须手动执行下面几个存储过程来删除Log Shipping在数据库中记录的信息。
1、sp_delete_log_shipping_primary
删除msdb.dbo.log_shipping_primary表中的Primary Server信息
2、sp_delete_log_shipping_plan
删除Log Shipping计划
3、sp_delete_log_shipping_secondary
删除msdb.dbo.log_shipping_secondaries表中的Secondary Server信息
4、sp_remove_log_shipping_monitor
删除Log Shipping监视从表msdb.dbo.log_shipping_monitor
二、数据库的模式
如果正确设置了Log Shipping，但是没有办法正常执行，在SQL Server的日志中可以看到类似这个信息和界面：
Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL Server 'ZTAO-1' as 'ZTAO-1\Administrator' (trusted)
Starting maintenance plan 'LOG_Plan_9' on 2003-9-4 14:42:02
Backup can not be performed on database 'ERPLogShipping'. This sub task is ignored.
Deleting old text reports... 0 file(s) deleted.
End of maintenance plan 'LOG_Plan_9' on 2003-9-4 14:42:02
SQLMAINT.EXE Process Exit Code: 1 (Failed)
可能是你没有正确设置数据库的模式，完整模式。
三、Log文件存放路径
在MSDN上看过一篇文章说，同一台电脑上再次设置Log Shipping时，不要使用相同的目录存放Log文件。这个没有考证过，只提一下，提醒大家！
|
本类阅读TOP10