Sco*_*red 12
SQL Server 专家Paul Randal在夏令时如何影响灾难恢复？. 这是一篇相对较短的文章，所以我引用了它的全部内容。由于您担心事务日志备份，因此我还突出显示了该帖子的一些内容，以引起您的注意。
众所周知，SQL Server 正确处理夏令时 (DST)，那么您为什么要关心呢？
嗯，众所周知，在 DST 结束时时钟倒退一个小时（在美国总是在 02:00），SQL Agent 基本上会暂停一个小时（至少在 SS2000 之后）。这意味着，如果您的作业每 15 分钟执行一次，则在 01:45 的作业执行和 02:00 的作业执行之间将有 75 分钟的间隔。发生这种情况是因为在 02:00，时间被设置回 01:00，但所有作业的下一次运行时间保持不变——因此您的作业在下一个预定时间 02:00 之前无法执行。因此，每年秋天在北半球和每年春天在南半球，您都会损失一个小时的 SQL 代理作业。不过，你为什么要关心？
嗯，这取决于延迟一个小时的工作是什么。如果您 的作业每 15 分钟进行一次日志备份，那么在 DST 结束 的那天，日志备份之间实际上有 75 分钟的间隔。如果您的服务水平协议 (SLA) 将发生灾难 时丢失的最大工作量限制为 15 分钟，那么在这 75分钟内，您可能无法满足该 SLA！
这可能是一件大事，特别是如果在那一小时出现问题（与其他任何时间出现问题的可能性差不多，但仍有可能）。在这种情况下，您需要提出替代解决方案。我能想到的解决问题的几种方法：
这两个都是可行的解决方案，但我认为最好的方法是创建一个在 01:59 运行的 SQL 代理作业，并创建在 01:00、01:15、01:30 和 01:45 运行的额外备份作业。我不明白为什么这不可能。今天早上 10 点 36 分，我创建了一个简单的代理作业，将日期打印到文件中，并将其设置为在过去的 09:40 执行。然后我将系统时间调回一小时，工作完美执行。此解决方案的唯一缺点是您需要使用嵌入在 01:59 作业的作业步骤中的 T-SQL 代理 SP 创建和安排额外的作业 - 乏味但并不难。也许有人可以给我发送一个脚本，我会在博客上将其作为后续内容？
因此，随着夏令时在 11 月 4 日结束，这绝对是您需要注意的事情，即使您不想为应对额外一小时的暴露而烦恼。顺便说一句——今年夏令时开始和结束的日期发生了变化。知识库文章 931975 讨论了 SQL Server 的哪些部分不知道更改的日期以及您可以对此做些什么。