为什么事务日志不是真正循环的？

Question

我最近做了一些关于 sql server 中事务日志如何工作的动手研究。我遇到了一个无法理解的问题。

首先，我创建了一个具有完全恢复模式的新测试数据库，并在其中创建了一个空测试表。然后我做了一个初始的完整备份，然后进行了第一次 tlog 备份。这导致以下 DBCC LOGINFO 输出：

到现在为止还挺好。之后我插入了几行，以确保前三个 VLF 正在使用中。作为我的下一步，我做了另一个 tlog 备份和手动检查点，因此前两个 VLF 被截断，导致此 DBCC LOGINFO：

然后我添加了更多行，以便事务日志环绕并且数据库引擎再次使用第一个 VLF。除此之外，我添加了越来越多的行，最后第二个 VLF 已满。由于第三个 VLF 还没有被截断，事务日志增长了，并且添加了四个额外的 VLF。在这一切之后，我做了下一个事务日志备份和一个手动检查点，最终导致了这个：

现在困扰我的是接下来发生的事情。我认为当我进行如此多的更改时，最后一个 VLF（此处为第 8 行）将变满，日志将再次环绕并再次开始写入第一个 VLF（此处为 FSeqNo 41），因为此 VLF已经被截断了。我预料到了这一点，因为在“ https://docs.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver15 "他们建议，事务日志具有循环性质。但真正发生的是，数据库引擎以最低的 FSeqNo 写入下一个 VLF：

为什么这种行为与 Microsoft 文档相反，或者，我只是不明白它对吗？任何帮助或解释将不胜感激。

Answer 1

面对日志文件增长事件和/或大型、长时间运行的事务，输出的顺序DBCC LOGINFO可能看起来有点古怪 - 至少暂时如此。

要记住的重要一点是VLFFSeqNo的逻辑顺序。

Paul Randal 在他的博客文章Inside the Storage Engine 中谈到了这一点：更多关于日志的循环性质（强调我的）：

一旦我创建的活动事务提交或回滚，VLF 3、4、1 和 2 可以清除，然后日志中 VLF 的“正常”排序将恢复。

每个 VLF 都有一个小标题，其中包含事务日志中 VLF 的序列号，因此日志可以进行某种扭曲以解决日志中间的活动 VLF。

随着 VLF 正常清除，这些不规则应该会随着时间的推移自我纠正。