减少高 VLF 计数

Question

我一直在使用Brent Ozar 的 sp_blitz 脚本来检查我们的数据库设置，发现自从更改为完整恢复模式后，主数据库上的 VLF 计数很高（13562！）。

我在周末运行了一次完整的索引重建，在此期间，日志文件在 46GB 数据文件上膨胀到大约 32GB，我认为这导致了高 VLF 计数。

据我所知，我应该提高自动增长，但这不是典型的活动。通常，每隔几个小时备份的 .trn 文件为 100-200MB，因此 10MB 似乎并不荒谬。

所以，我想我需要收缩日志文件，并允许它再次在尽可能少的生长尽可能脚本成长在这里出个小时。在这种特殊情况下，这听起来合理吗？

另外，日志文件的初始大小现在是 33896MB，我应该在缩小后将其减少到更合理的大小 (200MB) 吗？

Answer 1

10MB是荒谬的，恕我直言。您的 I/O 子系统在需要将增长限制为如此小的增量时是否很慢？理想情况下，您根本不应该观察 AutoGrow，将日志的大小设置为足够大以处理最大的事务。并且只使用 AutoGrow 作为拐杖来保护您免受异常事件的影响，例如这个，在这种情况下它应该相当大。

不，我不会将您的日志文件减少到 200MB，而且我不确定这如何“更明智”。增长的事件是昂贵的，特别是与日志文件，因为文件的扩展部分具有将被归零了。您希望以这样一种方式调整日志文件的大小，以避免任何可预测的增长事件。如果您将来要执行另一个类似的索引重建，我不明白同时将日志文件缩小到 200MB 会得到什么。您是否打算将腾出的空间租给其他人，然后在您的日志再次需要空间时将他们踢出去？我会说将日志保留在 32GB（缩小它并扩展它一个事件，正如您指出的脚本所建议的那样) 并监视 AutoGrow 事件（这些事件在默认跟踪中捕获，因此您无需进行任何设置，只需偶尔查看一下即可）。（在更现代的版本中，应该考虑使用扩展事件来代替跟踪增长事件。）这将告诉您是否需要考虑将其变得更大。

最小的日志文件没有奖励 - 您希望它足够大以容纳所有正常（和异常）日志活动而不必增长。