主页 / dba / 问题 / 190224
Accepted
SqlNovice
Asked: 2017-11-07 08:00:02 +0800 CST

夏令时备份计划

  • 772

日志备份的备份计划（使用Ola的脚本）如下：

  • 开始时间 - 凌晨 2 点
  • 结束时间 - 11.59.59PM
  • 间隔 - 每 15 分钟一次。

11 月 5 日，所有备份都按照上面的详细说明进行。通常在凌晨 1 点不存在日志备份，但在晚上 11:45 备份后的其中一台服务器上，在凌晨 1 点有日志备份，而其他服务器有从凌晨 2 点开始的日志备份。

我的问题是：为什么在凌晨 1 点在一台服务器上进行备份，而当时所有其他服务器都没有日志备份？这会破坏LSN吗？

恢复时我需要恢复晚上 11:45 然后凌晨 1 点然后凌晨 2 点等等？

LSN在下面给出

11 下午 45 点日志 - 第一个 LSN：85246:1956:1，最后一个 LSN：85246:3496:1

12.00 完整 - 第一个 LSN：85246:4241:180，最后一个 LSN：85257:583:1

凌晨 1 点日志 - 第一个 LSN：85246:3496:1，最后一个 LSN：86097:4867:1

凌晨 2 点登录第一个 LSN：86097:4867:1，最后一个 LSN：86105:2224:1，

2.15 am 日志 - 第一个 LSN：86105:2224:1，最后一个 LSN：86111:4864：

任何帮助将不胜感激。

sql-server transaction-log

1 个回答

  1. Best Answer

    根据日志文件中的 LSN，您应该没问题。

    如果从午夜进行的完整备份恢复，则不需要 11:45 日志文件（完整备份应该完全覆盖它）；你会恢复：

    • 完整备份
    • 凌晨 1 点的日志文件
    • 凌晨 2 点的日志文件
    • 2:15 日志文件
    • 等等。

    至于为什么在凌晨 1 点进行日志备份？我只能推测。

    如果该服务器上没有凌晨 2 点日志备份，则凌晨 2 点日志备份至少有可能在系统时钟将时间转移到凌晨 1 点之前设法启动，并在发生后记录其活动。如果发生这种情况，当它去设置下一次运行的时间时，它可能会再次安排在凌晨 2 点，因为它会看到时间是（比如说）1:01:07。我不会说它有可能，但我个人不能排除这种可能性（也许其他人可以）。更大胆地推测，如果这只发生在一台服务器上，则它的时钟芯片可能存在一些问题。该服务器是否具有任何独特性（例如，服务器场中最旧的服务器）？再一次，这是疯狂的猜测，除了渺茫的可能性，我没有什么可以提供的。

    更有可能的是：是否有可能在 11 月的第一个星期日凌晨 1 点设置了一个旧作业来进行日志备份，或者类似的事情？

    • 1

相关问题