SQL Server 2012 索引重组日志文件增长

Question

我的 SQL 2012 SP3 服务器被配置为通过维护计划在每个周末运行索引重组作业（不是我的电话，这是政策，我保证！）。我有一个 30GB 的数据库（不包括日志文件），其中事务日志文件在索引重组后增长到几乎 30GB。在这个实例中还有其他几个大小相似的数据库，但日志文件很小，从 17MB 到 2.5GB 不等。我已经阅读了许多论坛和文章，试图确定为什么这个特定的日志文件会变得如此之大。唉，我失败了，这就是为什么我现在要求开悟。

以下是一些配置：

请注意，跨数据库的大多数配置都是相同的（基于 sys.databases）。

• 恢复模式 = 完整（在所有数据库上）
• is_FullText_Enabled = 1（很多，不是所有的数据库都启用了这个），这里似乎有一些相关性，在 is_FullText_Enabled = 1 的地方，日志文件似乎更大。
• 在此实例中没有任何类型的复制/事务日志传送。
• 日志备份每 3 小时运行一次，这是增长问题的一部分，但不允许更改计划/频率。

以下是我尝试过的一些事情：

• 将日志缩小到 10MB 以降低 VLF，然后将其增长到 24G。
• 手动运行索引重组几次以查看碎片是否会减少并最终停止增长日志文件，但这并没有帮助。
• 我什至重建了索引（通过维护计划在线）并尝试了随后的索引重组，但日志又重新长出来了。
• 在 reorg/rebuild 尝试之间缩小日志文件。是的，shrink = 糟糕，我知道，糟糕的 DBA，糟糕！

是的。索引维护已记录，我明白了，但是为什么数据库之间的日志文件增长存在很大差异？我错过了什么？是什么导致此日志文件比其他日志文件增长得如此之大？

我是新手，请让我更聪明，谢谢。:)

Answer 1

在完整恢复模型中，内部日志截断取决于您进行日志备份。如果您在它们之间等待三个小时，那么您将有三个小时的交易时间。

正如您所指出的，索引维护已完全记录。如果您真的对数据库中的每个索引（或者甚至是其中的大部分 - 很难说不知道您重新组织索引的阈值是多少），那么您的日志文件完全有可能需要容纳其中的每个索引日志备份之间。

假设在 30 GB 的数据库中，您以 5% 的碎片（一种常见策略）重新组织索引，并且其中大多数都达到了这个水平。您需要对所有这些执行一些操作。在其他数据库中，如果您具有相同的阈值，则它们可以接触的索引可能要少得多。这可以解释这种差异。

我知道这里没有太多东西在你的控制之下，但如果我有我的 DBA druthers，我会想要

• 进行更频繁的日志备份
• 执行不那么激进的维护
• 使用Ola Hallengren 的免费脚本

使用 Ola 的脚本是轻而易举的。您可以设置非常具体的级别来重组或重建，跳过或包含哪些索引，以及您希望以什么大小执行某些活动。我知道这不是你的问题，但如果你选择与管理层分享，如果我不包括它，我会是一个坏人。

另一面？Ola 脚本运行的所有操作都会记录到表中，因此您可以查看实际发生的情况。如果您想找出发生某些事情的原因，这对于取证来说是最重要的事情。

希望这可以帮助！