相关疑难解决方法(0)

每季度，我通过 CMS 使用来自github 上的tigertoolbox/Fixing-VLFs/的查询检查我所有服务器上的 VLF 。这包括用于更正所发现内容的建议（和代码）。在进行任何调整之前，我总是尝试充分了解正在发生的事情。我应用的 VLF 解决方案在 90% 的情况下与建议不同，尽管它通常很接近。

使用DBCC LOGINFO我发现有几个 VLF 没有按顺序使用。我试图理解为什么。这个高度投票的答案; 即使在 BACKUP LOG TO DISK说它可能发生后，日志文件上的 DBCC SHRINKFILE 也不会减小大小 ，但不是为什么。

因为虚拟日志文件并不总是按顺序分配的，

这似乎与Jonathan Kehayias相冲突；一天的 XEvent（31 个中的 23 个）——它是如何工作的——多个事务日志文件

我们可以看到，在 130 VLF 中，目前仅使用了两个（第 51 和 52 行）。最大的 FSeqNo 是 41808，减去 130 = 41678。我没有看到任何低于 41678 的 FSeqNo，所以大概在最近的 130 次 VLF 翻转中都使用了。

如果我们查看第 108 - 109 行，我们会看到第 110 行首先被写入，然后是第 109 行，然后是第 108 行。而且奇偶校验关闭（不确定这会增加场景的内容）LSN 显示它们是在相反的位置创建的命令。

我希望一旦导致顺序中断的原因过去了，下一次通过 VLF 将按创建的顺序写入。为什么不是？

注意第 86 …