夏令时

在我的环境中，有一些服务器在本机备份和Ola Hallengren计划上运行。我们的服务器是2008年，2012年和2014年的组合。所有完整备份均在凌晨12点进行，日志备份每15分钟进行一次。

我以前从未考虑过夏令时，因此请告诉我应该进行哪些调整。

凌晨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 Agent工作价值。还是，你为什么要在乎呢？

好吧，这取决于要延迟一个小时的工作。如果您 有一项工作每15分钟进行一次日志备份，则DST 结束的 那一天实际上是两次日志备份之间有75分钟的间隔。如果您有一个服务水平协议（SLA）， 在发生灾难时 将最大丢失工作量限制为15分钟，那么对于这75 分钟，您很可能无法达到该SLA！

这可能是一个很大的问题，尤其是如果在该小时内出现问题的情况下（发生错误的可能性不超过任何其他时间，但仍然可能）。在这种情况下，您需要提出一个替代解决方案。解决该问题的几种方法我可以想到：

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

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

因此，随着DST于11月4日结束，这绝对是您要注意的事情，即使您不想麻烦应对额外的一小时曝光也是如此。顺便说一句– DST开始和结束的日期今年发生了变化。KB文章931975讨论了SQL Server的哪些部分不知道更改的日期以及您可以采取的措施。