SQL Server 在日志备份中的哪个点截断日志文件？

Question

我正在调查一个问题，即我们的第三方备份软件在工作日期间开始对我们的某些数据库进行完整备份的时间有些可预测。它启动日志备份，检测 LSN 中的断链，然后将其转换为完整备份。

我检查过，没有针对我们遇到的 SQL 服务器运行其他日志备份。

发生的情况是日志备份按计划开始，但有时在备份期间与备份服务器的连接丢失。该作业处于不确定状态，当它以相同的作业 ID 重新启动时，会检测到一条断开的链，并开始对受影响的数据库进行完整备份。

搜索日志，我可以看到备份失败和备份使用不再存在的相同 LSN 重新启动。

所以我的问题是，当使用 truncate 选项进行日志备份时，SQL Server 是在备份日志时还是在成功完成作业时截断日志？在我的情况下，似乎正在备份一系列 LSN，标记为已备份，当作业失败时，它会在作业重新启动时再次查找相同的 LSN。

Answer 1

从技术上讲，虚拟日志文件 (VLF) 仅在成功备份并且不再需要内部（有时是外部）进程（例如复制或可用性组）时才尝试将其标记为非活动（可以重用）。

发生的情况是日志备份按计划开始，但有时在备份期间与备份服务器的连接丢失。

这不会导致 SQL Server 出现任何问题。SQL Server 将看到连接中断并终止会话以及正在执行的任何内容。这意味着备份没有成功，因此下一个日志备份应该在同一个位置开始，因为它还没有成功完成。

该作业处于不确定状态，当它以相同的作业 ID 重新启动时，会检测到一条断开的链，并开始对受影响的数据库进行完整备份。

听起来应用程序认为它成功运行了备份，即使它没有并“检测到”有问题......但没有。听起来备份程序中的应用程序逻辑要么有缺陷，要么遇到配置问题……或者它可能是他们的标准逻辑（按设计）。

现在，如果它需要一个完整的备份然后走开......那不会影响日志重用。

但是在一周的某一天，在一天的某个时间，一半的作业挂起，因为备份服务器停机了几分钟，当它们再次重新启动时，它们开始对某些数据库进行完整备份。据我所知，它寻找 LSN，运行备份，作业失败，重新启动寻找相同的 LSN。

听起来您还有其他可能导致的基础设施问题。但是，假设它们不是，听起来备份应用程序很混乱。如果作业未能成功备份日志，它应该从同一位置开始，因为它尚未成功备份。如果备份应用程序选择将其视为问题并进行完整备份以在内部重置自身（备份应用程序），则由应用程序供应商来修复/决定/按预期工作/在您告诉他们之后进行任何操作。

但是，由于这仅在备份应用程序服务器出现故障时才会发生……您可能还希望与您的基础架构团队进行严厉的交谈并解决该问题 - 或者至少，如果由于修补或其他原因导致停机，所有作业都被保留，直到修补（或其他）完成。