SQL Server 2000之日志传送功能
设定，重新组态，与监控日志传送(Log Shipping)动作
原文出处: 2001/12 SQL Server Magazine
原文标题: Log Shipping in SQL Server 2000, Part 1
原作者: Ron Talmage
译者: 何致億
日志传送功能可自动复制数据库的交易日志文件，并回存到备援服务器 (standby server) 的另外一个数据库。因此可大幅提高SQL Server数据库之可用性。因为备援数据库完整地接收来源数据库的异动情况，所以它就是一份来源数据库的复本 — 差别仅在于资料复制与加载过程所产生的时间差。然而，当主要服务器停摆时，您就可以将备援服务器更改为新的主要服务器。如果原来的主要服务器可重新上线使用，那么您可以将其设定为新的备援服务器 — 事实上就是对调两台服务器的角色。
在SQL Server 2000企业版或开发版之中，Microsoft在Enterprise Manager内提供了一项日志传送(Log Shipping)的功能 — 为数据库维护计划精灵的其中一部份。在使用之前的SQL Server时，您需要自行建立日志传送系统；或是在SQL Server 7.0，Microsoft BackOffice 4.5 Resource Kit内有提供一项设定日志传送的工具,但使用此工具可能无法获得任何技术支持。如果您想获得更进一步的信息，请参阅2000年12月《Log Shipping with SQL Server 7.0》一文。
(为了验证本文的技术性细节部分，我采用SQL Server 2000企业版加上SP1。然而在SP1的修正清单中，并没有包含任何有关日志传送功能的修正。)
设定日志传送
主要服务器(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)。这些步骤将建立一组日志传送服务器(互相有日志传送关系的两个数据库)。如果您想要额外提供容错功能或是设定一台报表服务器，那么您可以将主要服务器与另外一台次要服务器组合在一起，再设定一组日志传送配对服务器。
逐步设定
为了观看精灵是如何运作的，让我们随着撷取下来的屏幕画面进行逐步设定。首先，先开启Enterprise Manager，展开主要服务器节点，再向下展开『Management』节点，然后就可以激活数据库维护计划精灵。
图2：数据库维护计划精灵 — 指定欲建立维护计划之数据库。
如图2所示：精灵的第一个画面中需选定来源数据库，然后勾选画面下方的【Ship the transaction logs to other SQL Servers (log shipping)】的复选框。一个来源数据库一次只能建立一个数据库维护计划。当来源数据库的复原模式 (recovery model) 是设定为full或是bulk_logged时，该复选框才可以勾选。因为这些复原模型才允许您备份交易日志文件。
接下来的数个画面是让您设定数据库维护计划的完整数据库备份，以及其它的维护动作。然而，如果您在一个维护计划内设定多项维护动作较容易产生混淆，所以我建议您将日志传送动作单独设定在一个维护计划内。
在 『Specify Transaction Log Backup Disk Directory』的画面中，请勾选 【Use this directory】复选框，并且指向主要服务器上存放资料日志文件的目录位置。请确认【Remove files older than】设定的时间周期能够让主要服务器之日志文件保留足够的时间(至少要能在例行性备份计划中将之备份完毕)。如果您设定的周期太短，且次要服务器上的复制日志文件工作恰好失败，那么主要服务器上的SQL Agent工作就会在复制档案到次要服务器之前就先清除交易日志文件，日志传送动作因而失败。指定交易日志文件之扩展名为.trn的作用则是让维护计划以dbname_tlog_yyyymmddhhmm.trn的格式命名日志文件。
下一个窗口为『Specify the Transaction Log Share』，只有当您在维护计划中加入日志传送时才会出现。在此窗口中您必须指定主服务器上的分享目录名称。您可以按下【…】按钮后浏览目录名称。
在『Specify the Log Shipping Destinations』窗口内允许您一次设定一台以上的次要服务器。点选【Add】按钮后可开启『Add Destination Database』对话框，如图3所示。您可以输入所有次要服务器的相关信息。
图3：设定次要服务器之相关信息。
【Server Name】下拉式选单会列出您在先前准备工作中曾利用Enterprise Manager所注册的次要服务器名称。在【Directory】文字字段里，请输入次要服务器的目录名称，用以接收来源数据库交易日志文件复本；此名称为本地端路径名称，而不是分享目录名称。您可以使用【Create and initialize new database】选项，SQL Server会在次要服务器上建立并初始化新的数据库。假设您已经完成数据库回存动作，那就可以使用【Use existing database (No initialization)】选项。如果数据库很大，您可能会希望在离峰时间进行备份与回存动作。
目的数据库必须设定为非复原(nonrecovered)状态，SQL Server才能回存交易日志文件。有关数据库的加载状态，您有两种选项可以设定：复原模式(recovery mode)与备援模式(Standby mode)。所谓的『复原模式』表示使用者将无法进行资料查询，唯一可执行的动作只有回存交易日志文件。而『备援模式』则是将数据库设定成只读状态；只要不是在回存数据库的时候，您都可以查询资料。『Add Destination Database』窗口内还有一个【Terminate users in database (Recommended)】选项，会在回存数据库(译注1)或是回存交易日志文件时发生动作。在回存数据库或是交易日志文件时，『回存程序』将是数据库内唯一的使用者。所以，Microsoft建议您勾选此选项，否则其它使用者可能会影响回存动作的进行。
译注1：这里假设您在『Add Destination Database』窗口中是选择了【Using existing database (No initialization)】选项。
您或许也想勾选【Allow database to assume primary role】复选框，这个选项可让目的数据库变为新的日志传送数据库，因此允许您以后在主要服务器与次要服务器之间进行可能的角色对调。当您勾选此选项时，请将次要服务器上交易日志文件的分享目录设定为(新来源数据库)交易日志文件备份之目录位置。
下一个『Initialize the Destination Databases』窗口内，您可以挑选最近一次的备份资料；或是建立一份新的备份资料。对大型数据库而言，使用既有的备份资料会比较有效率。然而，从那次备份之后的所有交易日志文件都必须存在于主要服务器上交易日志文件的分享目录之中，精灵才有办法复制与回存到次要服务器。如果数据库不是很大，那么让精灵产生新的备份将会比较简单。
在『Log Shipping Schedules』窗口中，您可以设定来源数据库上交易日志文件的备份频率；也可以设定次要服务器上SQL Agent工作 (由精灵建立的，用来复制与加载交易日志文件) 的频率。日志传送的频率可粗略设定为一分钟一次；但以大型数据库来说，五分钟一次是比较普遍的选择。
『Log Shipping Thresholds』窗口则是让您针对交易日志文件备份动作，以及复制与回存工作，设定合理的延迟时间。当超过临界时间时，日志传送监控程序对话框将会响应一个警示讯息。
谈到监控服务器，下一个『Specify Log Shipping Monitor Server Information』窗口可让您指定监控服务器是哪一台。这里请小心：您可能会直接使用默认值，但是预设监控服务器是设定为主要服务器。一般来说，您不会把主要或次要服务器当作监控服务器，这是因为如果其中一台服务器故障停摆时，您将无法得知目前日志传送的状态为何。
在经过几个回报讯息的窗口后，精灵的最后一个步骤让您指定此执行计划的名称。我建议为了辨识方便起见，可将log shipping这个名词当作名称的一部份。如果未来有可能变动服务器，那么您可能不会把服务器名称加入维护计划的名称中。按下【Finish】吧！此时精灵会自动从主要服务器与次要服务器之间设定日志传送动作，并且在监控服务器上设定日志传送监控程序。
更改日志传送之组态设定
您可以使用数据库维护计划之【Properties】对话盒来更改日志传送相关设定。在【Transaction Log】设定页提供的选项可更改日志传送过程中交易日志文件备份的组态。【Log Shipping】设定页显示出您先前在维护计划内设定的日志传送配对服务器；如果您设定了其它组日志传送配对服务器，也会列在此处。本设定页也包含下列选项：新增目的数据库(用以建立新的日志传送配对服务器)、删除既有日志传送配对服务器、编辑目前的日志传送配对服务器之属性，以及移除整个日志传送功能。
当您在【Log Shipping】设定页之中点选【Edit】时，将开启【Edit Destination Database】对话盒。您可以在对话盒内【General】设定页检视与修改次要服务器的交易日志文件之目录位置，以及未来做为主要服务器时分享目录之路径。【Initialize】设定页则可让您更改复原模式，以及次要服务器上复制与回存之频率。【Thresholds】页可以设定日志传送之临界周期，如图4所示。
图4：更改日志传送之组态设定页。
在【Out of Sync Threshold】项目可设定：当日志传送监控程序产生警示讯息之前所能允许的最大时间间隔 (介于最近一次来源数据库交易日志文件备份以及最新的交易日志文件回存动作之间)。您也可以在日志传送监控程序之中设定此参数。【Load Time Delay】、【File Retention Period】以及【History Retention Period】则是与次要服务器相关的设定。
监控服务器在这些组态选项中扮演相当重要的角色。因为【Log Shipping】设定页的大部分信息取决于监控服务器，所以一但监控服务器停摆时，您将无法更改日志传送的组态设定值。我发现在监控服务器执行SQL Server 2000 Profiler时，主要服务器会连到监控服务器，然后从日志传送资料表中取得既有的日志传送计划。因此，要改变日志传送计划的设定时，您必须确定在Enterprise Manager内可以连接到监控服务器。
检查与监控日志传送动作
如果您已熟悉SQL Server 7.0的日志传送，或是您已建立过自己的日志传送系统，您应该是在次要服务器上监控日志传送的动作。然而，SQL Server 2000的日志传送功能还提供了一项日志传送监控程序，可让您安装在另一台独立监控用服务器。
那么SQL Server 2000是将日志传送的相关信息储存在何处呢？在SQL Server企业版与开发版的msdb数据库中共有七个关于日志传送的资料表：
n log_shipping_plans
n log_shipping_plan_databases
n log_shipping_databases
n log_shipping_plan_history
n log_shipping_monitor
n log_shipping_primaries
n log_shipping_secondaries
上述每一个资料表都存在于主要、次要以及监控服务器上。各服务器也会使用某些资料表储存资料，视该服务器在日志传送系统的角色为何。
在主要服务器上检视日志传送动作 从Enterprise Manager 里，您可以登入主要服务器，并观察与监控日志传送动作。如果某个数据库已设定要进行日志传送，在数据库【Properties】对话盒的【General】页可得知该数据库的角色(来源数据库；或是目的数据库)，也可知道日志传送监控程序是位于那一台服务器上。您可以在Enterprise Manager内SQL Server Agent的Jobs节点，检视日志传送与交易日志文件备份工作所执行的状态与历史纪录。主要服务器只使用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 复制与回存工作)得到的更为详尽。
如图5所示:：当您开启配对服务器之属性对话盒，并进入【Status】设定页时，您可检视此配对服务器执行备份与回存程序之状态。
图5：配对服务器之属性对话盒。
其状态(Status)可以是Normal 或是Out-of-Sync。如果SQL Server Agent尚未复制或回存交易日志文件，对话盒内将会显示日志文件名为first_file_000000000000.trn。这并不是实际的文件名称，只不过是用来标示SQL Server Agent尚未处理任何档案而已。在【Status】设定页也会显示备份、复制以及加载(回存)等动作执行时所耗费的时间(译注2)。此设定页之信息不会自动更新，所以您必须将此对话盒关闭后再开启，才能更新其资料。
译注2：即图5之Backup delta，Copy delta与Load delta。
SQL Server只使用msdb数据库内两个资料表来储存日志传送服务器之相关资料。SQL Server在这两个资料表中都给予一个ID做为连结，以及一个外来键(foreign key)。该外来键是设定在log_shipping_secondaries资料表上，并参照log_shipping_primaries资料表的primary_id字段(这两个是所有日志传送资料表中唯一具有外来键关系的资料表)。在log_shipping_primaries资料表内的每笔资料都包含日志传送的相关信息，例如：来源数据库名称、交易日志文件备份工作执行之状态，以及已规划的停摆信息(可避免不必要的警示讯息)。而log_shipping_secondaries 资料表之每笔资料关于目的数据库之信息；每个目的数据库附属于特定的日志传送来源数据库。这两个资料表互相连结的结果就是日志传送监控程序内所显示的配对服务器信息。
每个配对服务器的『Log Shipping Pair Properties』对话盒也包含【Source】与【Destination】设定页，分别可让您调整backup failure与out-of-sync这两个警示讯息之临界时间值。这两个警示讯息分别对应到监控服务器上两个SQL Server Agent工作：” Log Shipping Alert Job - Backup” 以及 “Log Shipping Alert Job - Restore”。预设情况下，每项工作都是一分钟执行一次。当日志传送服务器之任何备份延迟时间超过backup-alert之临界值；或是复制与回存程序的延迟时间超过out-of-sync的临界值，这些工作都会在Windows 2000(或是Windows NT)的应用系统纪录文件中产生一个错误讯息。
移除与重新组态日志传送功能
如果您想从数据库维护计划中移除日志传送功能，可参考下列方式：开启该计划的属性对话盒，选择【Log shipping】设定页，然后点选【Remove Log Shipping】。此动作将从次要服务器上移除SQL Server Agent的备份与回存工作，并清除日志传送资料表内的所有相关资料。此外，日志传送监控程序的相关信息也会一并被清除。然而此动作将会适当地保留主要服务器上SQL Server Agent的交易日志备份工作。只有在删除数据库维护计划时，该工作才会被移除。假如您想从监控服务器内移除掉日志传送监控程序，请用手动方式将log_shipping_primaries与log_shipping_secondaries这两个资料表(位于监控服务器的msdb数据库)的资料删除即可。
如果您在数据库维护计划内设定日志传送时，就已允许目的数据库可以做为新的日志传送来源数据库。当您删除主要服务器的维护计划时，次要服务器上仍然会保留其数据库维护计划，以及交易日志文件备份工作。删除这些项目的方式是将次要服务器上与日志传送相关的数据库维护计划直接删除。
当您进行SQL Server 2000日志传送的实验时，也许偶而会中断设定过程。如果真是如此，那么某些资料仍然会存入每台服务器的日志传送资料表，并且影响到后续的日志传送设定动作。( 关于更进一步的信息，请参阅Microsoft 技术文章 《BUG: All Changes May Not Be Rolled Back When Log Shipping Maintenance Wizard Fails》，位于http://support.microsoft.com/support/kb/articles/q298/7/43.asp )
为了保证这些剩余资料都会被清除，请确实删除每台服务器msdb数据库内日志传送资料表之相关资料。
接下来：角色对调
现在您已经可以设定与组态日志传送了，您还需要熟悉如何在必要时对调主要服务器与次要服务器之角色。在本系列第二部分内容中，我将介绍：如何改变日志传送的角色、如何对调日志传送的角色，以及如何在SQL Server 2000标准版使用日志传送功能。
角色变更、角色互换、以及监控服务器所在位置
原文出处: 2002/01 SQL Server Magazine
原文标题: Log Shipping in SQL Server 2000, Part 2
原作者: Ron Talmage
译者: 何致億
当线上数据库停摆时(可能是计划内维护工作，或是预期外的状况)，如果还有备援服务器上的数据库可供存取，您可能会比较安心一点。一个设计良好的日志传送系统(将数据库交易日志文件从主要服务器传送到备援服务器)即可给予您这样的自信心。内建于 SQL Serve 2000 企业板与开发版的 Enterprise Manager 工具程序即支持日志传送功能。而Microsoft SQL Server 2000 Resource kit 内含某些日志传送专用预存程序，可使用在其它 SQL Server 2000 版本。Microsoft BackOffice Resource Kit (BORK) 4.5 也提供 SQL Server 7.0 可使用的日志传送方法 (针对以上两点Microsoft 均不提供技术支持)。在 2001年12月《SQL Server 2000之日志传送功能- Part 1》文章中(译注[1])，我曾经说明过如何设定、重新组态、以及监控日志传送。本期我们将探讨如何变更主要/次要服务器(primary/secondary server)之角色、如何完全互换这两个角色，还有如何选择监控服务器(monitor server)所在位置，以建构效率最佳的监控环境。
角色变更
将日志从主要服务器传送到次要服务器之后，您可在必要时以次要服务器置换掉主要服务器。如果主要服务器发生问题，或是计划性停摆(例如升级硬件或安装修正程序)，线上数据库就必须停止服务一段期间。此时您可以变更次要服务器上数据库之角色，让它取代主要服务器之后进而成为线上数据库。SQL Server 2000 线上手册(Books Online，BOL)将此项操作称为日志传送角色变更(log shipping role change)。在日志传送过程里，次要服务器需设定在无法复原(nonrecovered)状态，因此交易日志才能从主要服务器回存到次要服务器(一但您将数据库复原，就不能再回存交易记录)。变更角色时，您需将次要服务器的数据库予以复原，并标示其为新主要服务器数据库。您也可以将旧主要服务器数据库设定为新次要服务器数据库。如果旧主要服务器数据库并未损坏，那么就可以在新主要服务器与旧主要服务器(已变成新次要服务器)之间重新建置日志传送功能。这种切换方式我们称为角色互换(role reversal)。
虽然 SQL Server 2000 已提供 Enterprise Manager 程序让您进行日志传送的组态与监控工作，但是它对于日志传送变更的支持却相当有限。您必须手动执行 msdb 数据库内含的系统预存程序才能完成。在 SQL Server 线上手册《How to Set Up and Perform a Log Shipping Role Change (Transact-SQL)》(译注[2])一文可找到完整操作指引。我已将这些操作指引重新修订为六个基本步骤，分别为： 转移与汇出登入帐号，降级(demote)主要服务器，升级(promote)次要服务器，通知监控服务器角色已变更，在次要服务器上解析登入帐号，以及连结数据库存取与权限。让我们详细探讨每个步骤。
步骤 1: 转移与汇出登入帐号 首先，BOL 建议您建立一个SQL Server 2000 DTS封装(package) (译注[3])，用来将主要服务器的登入帐号转移到次要服务器，且执行各服务器间登入帐号SID之解析动作。转移登入帐号所用的 DTS Transfer Logins Task(译注[4])只能在 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 参数将依旧维持服务器上所有复写设定。
上述 sp_change_secondary_role 预存程序仅限使用于次要服务器数据库，否则会失败。我曾在执行此预存程序时发生问题；明明没有任何使用者正在存取数据库，它却告诉我数据库目前为使用中。解决的方式为重新执行一次该预存程序。
当预存程序执行完毕且让数据库重新上线时，它将会送出一个讯息告诉您 RESTORE DATABASE 指令已成功执行。
假如您曾选择让次要服务器成为未来潜在的主要服务器，则数据库维护计划会在次要服务器上建置一个交易日志备份工作(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 登入帐号能够正确地连结相对应的数据库使用者名称。
到此为止，您已经成功地将次要服务器升级为新的角色，而旧主要服务器也早已变成次要服务器。然而，您仍然尚未建置新的日志传送关系。您完成的只是角色变更，而不是角色互换。
角色互换
为了达成完整的日志传送角色互换，您只需在新主要服务器与新次要服务器之间重新设定一次日志传送即可。因为新主要服务器已内含崭新的数据库维护计划，您将会倾向在维护计划内直接加入新次要服务器，做为目的服务器。然而经过多次尝试之后，我发现新主要服务器的 ”交易日志备份工作” 总是会失败，并且日志也不会从新主要服务器传送到新次要服务器。
所以，您需要另外一种方法。您在执行过日志传送角色变更的预存程序，以及先前我详细说明的步骤后，就可以直接达成完整的角色互换 — 在新主要服务器与新次要服务器(译注[5])之间建置一份新的日志传送计划。为了建置该计划，您需遵循下列步骤：
1. 在新主要服务器的数据库维护计划内移除日志传送功能。
2. 在主要服务器上删除数据库维护计划。
3. 在次要服务器上删除数据库维护计划。
4. 维持所有交易日志文件。
5. 在新主要服务器上建立一个新的数据库维护计划，指定新次要服务器所在、目的数据库位置、以及交易日志文件之适当存放位置，如同我在 Part 1所介绍的内容。
6. 重新开始新主要服务器的所有活动。
在您成功设定角色互换且建置新日志传送配对服务器之后，Enterprise Manager 的日志传送监视器可能会告知您新次要服务器数据库并未与新主要服务器数据库取得同步(out of sync)。如果 ”最近一次加载的交易日志” 与 ”最近一次备份的交易日志” 之间的时间差超过了 out-of-sync 设定值，您就会收到此报告。直到最近一次的备份资料被加载之后，日志传送监视器就会回到平常无错误状态。
日志传送监视器所在位置
如同我在 Part 1 所说明的，Microsoft 强烈建议您将日志传送监视器置放于独立服务器上。如此一来，无论主要服务器或是次要服务器执行工作失败时，该监视器都会送出警示(alert)。如果监视器位于主要或次要服务器其中之一，报告结果将取决于监视器所在服务器。如果监视器所在服务器因故停摆，它将无法继续回报可能的错误情况。所以，要让监视器独立回报日志传送系统内主要或次要服务器上可能发生的问题，给予监视器一台独立服务器是较佳的实作方式。此外，您也可以使用这台独立的监控服务器去监控其它日志传送配对服务器。
如果您没有其它服务器可安装监控程序，而需要放在主要或次要服务器其中之一。究竟应该把日志传送监视器放在哪台服务器呢？因为您的重点是想侦测主要服务器上可能发生的日志传送问题，所以放在次要服务器比较妥当。如果将日志传送监视器放在主要服务器上，当主要服务器停摆时，您就无法使用该监视器，监视器也无法在日志传送发生问题时送出警示。所以呢，如果只有两台服务器可使用，次要服务器为置放日志传送监视器较佳的位置。某些时候，为避免灾难发生时影响次要服务器，您必须将交易日志从某一实体位置传送到另一个地方(也许有一段距离)。在此情况下，日志传送监视器最好放在其它地方的独立服务器，让灾难发生时不至于影响主要与次要服务器。
显著的改进事项
SQL Server 2000 内建的 Enterprise Manager 已支持日志传送设定与监控动作。然而，角色变更与角色互换仍需要耗费额外的功夫。因为 Enterprise Manager 的日志传送程序还无法变更日志传送角色，您必须手动执行某些预存程序。再者，欲达成完整角色互换也需要好几个迂回步骤。而 Enterprise Manager 的日志传送程序却没有提供将日志传送设定与移除相关动作予以指令化(scripting)之方法，但是数据库复制(replication)却有提供。尽管如此，SQL Server 2000 日志传送程序与之前版本相较之下，已提供了显著的改进，让设定与管理工作更加简单与直觉。
posted on 2004-03-03 12:53 Goodspeed 阅读(1304) 评论(0) 编辑 收藏 举报
