夏令时

SQL Server 专家Paul Randal在夏令时如何影响灾难恢复？. 这是一个相对较短的帖子，所以我将其全部引用。由于您担心您的事务日志备份，因此我还强调了一些帖子以引起您的注意。

众所周知，SQL Server 可以正确处理夏令时 (DST)，那么您为什么要关心呢？

好吧，在 DST 结束时，当时钟倒退一小时（美国总是在 02:00）时，SQL 代理基本上会暂停一个小时（至少从 SS2000 开始），这并不是众所周知的知识。这意味着，如果您的作业每 15 分钟执行一次，那么在 01:45 的作业执行和 02:00 的作业执行之间会有 75 分钟的间隔。发生这种情况是因为在 02:00，时间设置回 01:00，但所有作业的下一次运行时间保持不变 - 因此您的作业要到下一个计划时间 02:00 才能执行。因此，每年秋天在北半球，每年春天在南半球，您都会失去一个小时的 SQL 代理作业。不过，你为什么要关心？

好吧，这取决于延迟一个小时的工作是什么。如果您 的作业每 15 分钟进行一次日志备份，那么在 DST 结束的那一天，日志备份之间实际上有 75 分钟的间隔。如果您的服务水平协议 (SLA) 将发生灾难时的最大损失工作量限制为 15 分钟，那么在这 75 分钟内，您可能无法满足该 SLA！

这可能是一件大事，特别是如果在那一小时内出现问题（与其他任何时间出现问题的可能性差不多，但仍有可能）。在这种情况下，您需要想出一个替代解决方案。我能想到的解决问题的几种方法：

• 让某人在那个小时内熬夜并进行手动日志备份。
• 切换到数据库镜像，它会不断地将日志流式传输到冗余服务器，因此不会影响 DST 问题。

这两个都是可行的解决方案，但我认为最好的解决方案是创建一个在 01:59 运行的 SQL 代理作业，并创建额外的备份作业以在 01:00、01:15、01:30 和 01:45 运行。我不明白为什么这是不可能的。今天早上 10:36，我创建了一个简单的代理作业，将日期打印到文件中，并将其设置为在过去的 09:40 执行。然后我将系统时间设置回一小时，作业完美执行。此解决方案的唯一缺点是您需要使用嵌入在 01:59 作业的作业步骤中的 T-SQL 代理 SP 创建和安排额外的作业 - 乏味但不难。也许有人可以给我发一个脚本，我会把它写在博客上作为后续？

因此，随着 DST 将于 11 月 4 日结束，这绝对是您需要注意的事情，即使您不想费力应对额外一小时的暴露时间。顺便说一句——今年 DST 开始和结束的日期发生了变化。知识库文章 931975 讨论了 SQL Server 的哪些部分不知道更改的日期以及您可以做些什么。