SQL Server有多种技术可以用于实现自动创建冗余数据拷贝，提供数据灾难恢复的功能。其中，日志传送(logshipping)是最早出现的技术之一。虽然日志传送“年纪”很大，但是它依旧凭借着其独有的特点，在SQLServer的灾难恢复技术中扮演着重要的角色。

　　日志传送的结构

　　日志传送的工作机制非常简单。它主要是通过最基本的数据库事务日志备份和还原任务，来保持两台或者多台机器之间数据库同步，以此来实现数据冗余、灾难恢复的目的。

　　这里先来看看在日志传送中各个服务器所扮演的角色。

　　主服务器和数据库

　　日志传送配置的“主服务器”(primary server)，是作为生产服务器的 SQL Server实例。主数据库是主服务器上希望备份到其他服务器的数据库。所有用户端发来的数据操作请求，都是由主数据库处理的。

　　主数据库必须使用完整恢复模式或大容量日志恢复模式，简单恢复模式由于无法做日志备份，所以不被日志传送所支持。在一个日志传送的环境中，如果您将数据库的恢复模式改成简单恢复模式，日志传送会立刻停止工作。

　　辅助服务器和数据库

　　辅助服务器(secondary server)是您想要在其中保留主数据库备用副本的服务器。在辅助服务器上的辅助数据库，可以配置为以下两种状态：

　　1. 无恢复模式(NORECOVERY):既不前滚也不回滚未提交的事务，数据不可读。

　　2. 备用模式(STANDBY):在恢复日志期间回滚所有未提交的事务，并且将所有未提交的事务保存为一个单独的Transaction UndoFile(TUF)文件，恢复过程通过该文件来维护事务的完整性，当恢复下一个事务的时候则恢复所有已提交的事务。这种状态下，数据库是可读的，此时该辅助数据库可被用于生成报表之类的只读的需求。

　　在日志传送的配置中，一台主服务器可以有多台对应的辅助数据库。在每个辅助数据库上都有主服务器上的主数据库的备份。比如，可以有3台辅助服务器，第1和第2台辅助服务器上的辅助数据库设置成NORECOVERY模式，提供冗余的灾备功能。即使某一台辅助服务器出现了问题，另一台辅助服务器依旧可以提供灾难恢复功能。第3台辅助服务器上的辅助数据库则可以设置为STANDBY模式，这样，可以把所有OLTP类型的请求都交给主服务器处理;把所有数据仓库类型的请求交给辅助数据库。这样一定程度上减轻了主数据库的负载，对数据库系统的性能提高也有好处。您可以通过查询系统表log_shipping_primary_secondaries来知道某个主数据库有哪些对应的辅助数据库。

　　另外，一台辅助服务器也可以包含存储在多台不同主服务器中数据库的备份副本。比如说，你可能有五台服务器，每台服务器都运行关键数据库系统。在这种情况下，可以只使用一台辅助服务器，而不必使用五台单独的辅助服务器。五个主系统上的备份都可以加载到这个备份系统中，从而减少所需的服务器数量并节省开支。

　　监视服务器

　　监视服务器是可选的，它可以跟踪日志传送的所有细节，包括：

　　主数据库中事务日志最近一次备份的时间。

　　辅助服务器最近一次复制和还原备份文件的时间。

　　有关任何备份失败警报的信息。

　　监视服务器应独立于主服务器和辅助服务器，以避免由于主服务器或辅助服务器的丢失而丢失关键信息和中断监视。一台监视服务器可以监视多个日志传送配置。在这种情况下，使用该监视服务器的所有日志传送配置将共享一个警报作业。

　　日志传送的工作机制

　　日志传送的工作机制非常简单。日志传送组件在主服务器上对数据库做日志备份，然后把日志备份文件复制到所有的辅助服务器上，最后在辅助服务器上将日志备份还原上去。通过不断重复这样的过程，就实现了主服务器和辅助服务器上数据库的同步。

　　所有这些备份/复制/还原操作当然不可能是人为触发。日志传送会在主服务器，辅助数据库，以及监视数据库上创建相应的作业来分别完成这些工作。每个服务器上的SQLServer Agent服务会每隔一定时间间隔来启动这些作业。

　　日志传送一共有4个作业，分别是备份作业、复制作业、还原作业和警报作业。这些作业是如何协作运行，完成数据传递的目标呢?

　　现在来分别讨论每个作业。

　　备份作业

　　日志传送在主服务器上为每个主数据库创建一个备份作业。它负责对数据库做日志备份，将备份操作的历史信息记录到本地服务器和监视服务器上，并根据作业的设置来删除旧的日志备份文件和历史记录信息。默认情况下，SQLServer Agent服务每 15 分钟执行一次此作业，当然间隔也是可以修改的。备份作业会把日志备份文件放到一个指定的共享目录上去，等待复制作业的操作。

　　从SQL Server 2008开始，SQLServer的企业版支持备份压缩的功能。用户在创建日志传送的时候，可以选择是否为备份作业启用备份压缩。这对于一些非常繁忙的系统会很有用，它可以减少服务器上由于备份造成的I/O操作，也可以减低复制日志备份文件所需要的时间。

　　SQL Server 2000日志传送的备份作业就是直接通过SQLServer Agent来执行Backup log命令。SQLServer 2005开始，日志传送开始使用一个叫做sqllogship.exe的可执行文件来执行备份/复制/还原的操作。您在SQLServer Agent中会找到一个名字为LSBackup_的作业。此处为启用日志传送的主数据库名字。该作业只有一个步骤，执行的操作是:

　　sqllogship.exe -Backup -server

　　命令中的对应的就是主数据库的唯一标识号。如果去查询主服务器的MSDB数据库中的log_shipping_primary_databases表的话你就会找到对应的primary_id。

　　对应的就是主服务器的实例名。Sqllogship.exe通过连接到主服务器，然后通过找到的主数据库，最后运行backup log命令来备份日志文件。

　　复制作业

　　日志传送在每个辅助服务器上会创建复制作业。它的作用就是将日志备份文件从主服务器的共享目录中复制到辅助服务器上的一个本地目录，并在辅助服务器和监视服务器中记录历史记录。与备份计划一样，该作业的默认执行间隔是15分钟一次，当然也可以修改成您做想要的间隔。

　　该作业的名字是LSCopy__。这里的是主服务器的实例名，而是辅助数据库名。

　　和备份作业一样，从SQL Server 2005开始日志传送使用sqllogship.exe来完成复制的操作。你会发现备份作业只有一个步骤，执行命令是

　　sqllogship.exe -Copy -server

　　命令中的是辅助数据库的唯一标识号。如果去查询辅助数据库实例上的MSDB数据库中的log_shipping_secondary_databases或者log_shipping_secondary表的话，可以找到对应的secondary_id。此外，命令中的是辅助数据库的实例名。

　　还原作业

　　日志传送在辅助服务器上为每个辅助数据库创建一个还原作业。此作业将复制到本机目录的日志备份文件，还原到辅助数据库。同时还原作业会将历史记录信息记录在本地服务器和监视服务器上，并删除旧文件和旧历史记录信息。还原的时候，根据日志传送配置的不同，还原作业会把数据库还原成NORECOVERY模式或者是STANDBY 模式。该作业的默认执行间隔是15分钟。

　　还原作业的名字是 LSRestore__。这里的是主服务器的实例名，而是辅助数据库名。

　　SQL Server 2005开始的日志传送使用sqllogship.exe来完成还原操作。还原作业只有一个步骤，执行的命令是：

　　sqllogship.exe -Restore -server

　　命令中的和参数与复制作业做执行的sqllogship.exe的参数是一样的。Sqllogship.exe通过连接辅助数据库实例，然后根据找到对应的辅助数据库执行还原操作。

　　警报作业

　　如果使用了监视服务器，日志传送将在监视服务器上创建一个警报作业。如果有多个数据库配置了日志传送并且它们都是用了这个监视服务器，那么所有这些日志传送配置都共享这一个警报作业。如果主数据库无法在指定时间范围内完成备份操作，或者辅助数据库无法再指定时间范围内完成还原操作，警报作业就会触发主数据库或辅助数据库的警报(Alert)。

　　如果没有使用监视服务器，日志传送将在主服务器和每个辅助服务器上创建一个警报作业。如果主数据库无法在指定时间范围内完成备份操作，主服务器实例上的警报作业会生成一个错误。如果或者辅助数据库无法再指定时间范围内完成还原操作，辅助服务器实例上的警报作业会调用raiseerror来引发一个错误。

　　警报作业的名字是LSAlert_。就是该作业所在的SQLServer实例名。该作业其实是在定期的执行一个系统存储过程sys.sp_check_log_shipping_alert，执行间隔默认是2分钟 。

　　有兴趣的话，您可以用sp_helptext来看看这个存储过程的定义。

　　日志传送作业的执行间隔

　　日志传送是利用SQL Server Agent来执行备份还原的作业，从而达到主副数据库同步的目的。由于作业是每隔一定的时间间隔才被SQL Server Agent触发的，因此主副数据库的同步也不是实时的。它们之间会有一定程度的延迟。这是日志传送技术的一个重要特征。如果发生灾难，这部分延迟可能会带来数据丢失。

　　日志传送的主副数据库同步的延迟到底会有多长呢?这是由备份作业、复制作业和还原作业的运行间隔决定的。不过，用户所关心的最大数据损失量仅是由备份作业运行的间隔所决定的。例如，上述3个作业的执行间隔都被设置为15分钟，那么主副数据库之前同步的延迟会在15到45分钟之间。但是，只要日志被成功备份下来，无论之后复制和还原操作会延迟多长时间，日志备份始终在那里，最终都会被还原到辅助数据库上去。最大的数据丢失，是从最后一次成功的日志备份开始到数据库发生异常这段时间范围内的所有数据变化。因此，对于备份间隔是15分钟的日志传送配置，最坏情况下就是损失15分钟内的数据。

　　你可以根据你所能接受的最大数据损失量来指定备份作业的执行间隔。对于非常繁忙的OLTP系统，建议可以适当地缩短备份间隔。这样除了可以减小数据库发生异常后的数据的损失量，还可以有效地控制主数据库的日志文件大小，防止由于没有及时截断日志而导致日志文件太大的问题。

　　但是，无论怎么减小备份作业执行的间隔，日志传送是永远无法保证两个数据库是完全同步的。SQLServer允许的作业执行最小间隔是10秒钟，因此理论上您至少会有10秒的数据损失。此外，将备份间隔设置的太小也会给主服务器带来额外的负担，一定程度上影响数据库的性能。如果你追求的是零数据损失的灾备方案，日志传送并不适合你。

　　在给定的辅助服务器上，用户可以让复制作业和还原作业使用和主服务器的备份作业一样的执行间隔，并且控制复制作业和还原作业开始执行的时间，让复制作业尽可能紧随着备份作业完成后执行，让还原作业紧随着复制作业完成后执行。这样，每个日志备份被创建后可以立即将其复制和还原。这有助于减少在主服务器出现故障之后使辅助服务器上线所需的修复时间。

　　相反，用户也可以有意地延迟复制作业和还原作业，或者把复制作业和还原作业的执行间隔设置为远大于备份作业的执行间隔。这样做可以延迟将事务日志备份恢复到辅助数据库。该延迟提供了一个时间间隔。在这个时间间隔内，用户可以响应主服务器上发生的异常或故障。这对于处理严重的用户错误是很有用的。比如说，如果用户错误地删除了某张表或表中的某些行，并且管理员知道误操作的时间，他就可以立刻暂停复制和还原作业，不让误操作被同步到辅助数据库上。然后，手动地将包含错误操作的日志备份复制到辅助服务器上，并使用restoredatabase命令中的stop

　　at参数将数据库在辅助服务器上还原到误操发生前的状态。然后，管理员可以选择切换数据库的角色，让辅助数据库上线运行;或者选择导出主数据库上已经丢失的数据，然后将其导回主数据库。

　　总之，可以灵活地设置各个作业的执行间隔，来满足不同的业务需求。

　　日志传送的故障转移

　　当主数据库发生异常后，您需要将应用切换到辅助数据库上。本节将介绍日志传送的故障转移过程。比较群集的故障转移，日志传送的故障转移无疑是要更麻烦些，需要很多的手工操作。所以如果仅使用日志传送，是很难达到很好的高可用性的。