《SQL Server 2012实施与管理实战指南》编辑推荐：读者既可以把这本书作为一部进阶学习的参考书籍，更深入地理解SQL Server的原理和运行规律；也可以把这本书作为一本工具书，在遇到问题时查阅解决办法。
《SQL Server 2012实施与管理实战指南》主要面向对Microsoft SQL Server有一定基础的数据库系统管理人员和开发人员，针对他们在日常工作中可能遇到的种种困扰提出解决方案。
《SQL Server 2012实施与管理实战指南》讨论的主题是面向实践，解决用户开发和使用SQL Server过程中常见的经典问题。在每个章节里，都会基于这个主题从经常遇到的问题入手，描述其表现形式，介绍其背后的运行机理与基本理论知识，介绍搜集和分析问题日志的方法，以及解决实际问题的可选手段。
2.3.3 日志传送作业的执行间隔
日志传送是利用SQL Server Agent来执行备份还原的作业，从而达到主副数据库同步的目的。由于作业是每隔一定的时间间隔才被SQL Server Agent触发的，因此主副数据库的同步也不是实时的。它们之间会有一定程度的延迟。这是日志传送技术的一个重要特征。如果发生灾难，这部分延迟 可能会带来数据丢失。
日志传送的主副数据库同步的延迟到底会有多长呢？这是由备份作业、复制作业和还原作业的运行间隔决定的。不过，用户所关心的最大数据损失量仅是由备份作业运行的间隔所决定的。例如，上述3个作业的执行间隔都被设置为15分钟，那么主副数据库之前同步的延迟会在15～45分钟之间。但是，只要日志被成功备份下来，无论之后复制和还原操作会延迟多长时间，日志备份始终在那里，最终都会被还原到辅助数据库中。最大的数据丢失是从最后一次成功的日志备份开始到数据库发生异常这段时间范围内的所有数据变化。因此，对于备份间隔是15分钟日志传配置，最坏情况下就是损失15分钟内的数据。
你可以根据所能接受的最大数据损失量来指定备份作业的执行间隔。对于非常繁忙的OLTP系统，建议适当地缩短备份间隔。这样除了可以减小数据库发生异常后的数据的损失量，还可以有效地控制主数据库的日志文件大小，防止由于没有及时截断日志而导致日志文件太大的问题。
但是，无论怎么减小备份作业执行的间隔，日志传送是永远无法保证两个数据库是完全同步的。SQL Server允许的作业执行最小间隔是10秒，因此理论上你至少会有10秒的数据损失。此外，将备份间隔设置的太小也会给主服务器带毒额外的负担，一定程度上影响数据库的性能。如果你追求的是零数据损失的灾备方案，日志传送并不适合你。
在给定的辅助服务器上，用户可以让复制作业和还原作业使用和主服务器的备份作业一样的执行间隔，并且控制复制作业和还原作业开始执行的时间，让复制作业尽可能紧随着备份作业完成后执行，让还原作业紧随着复制作业完成后执行。这样，每个日志备份被创建后可以立即将其复制和还原。这有助于减少在主服务器出现故障之后使辅助服务器上线所需的修复时间。
相反，用户也可以有意地延迟复制作业和还原作业，或者把复制作业和还原作业的执行间隔设置为远大于备份作业的执行间隔。这样做可以延迟将事务日志备份恢复到辅助数据库。该延迟提供了一个时间间隔。在这个时间间隔内，用户可以响应主服务器上发生的异常或故障。这对于处理严重的用户错误是很有用的。比如说，如果用户错误地删除了某张表或表中的某些行，并且管理员知道误操作的时间，他就可以立刻暂停复制和还原作业，不让误操作被同步到辅助数据库上。然后，手动地将包含错误操作的日志备份复制到辅助服务器上，并使用restore database命令中的stop at参数将数据库在辅助服务器上还原到误操发生前的状态。此后，管理员可以选择切换数据库的角色，让辅助数据库上线运行，或者选择导出主数据库上已经丢失的数据将其导回主数据库。
……
