Server自动增长处理

Question

我有这样的设想：

• 初始大小为1193的DB日志，自动增长100 MB无限
• 每天早上8点，我会有20个自动增长事件每秒发生，这就是我的问题所在。

这里的正确解决方案是调整日志文件的大小，使自动增长不会频繁触发吗？在调整db日志文件之后，是否也应该将自动增长大小更改为类似500 db，以便在日志文件达到最大文件大小时至少限制自动增长事件的数量？

Answer 1

您可以通过增加增长因子来减少增长事件的数量，但是要小心。日志文件无法利用即时文件初始化，因此如果增长因子过高，可能会在自动增长事件中造成延迟。

您还需要考虑将根据增长增量和增长事件数量创建的VLFs数量。请查看金伯利·特里普的这篇文章，以获取VLF信息。

如果您的日志文件的大小不断增加，这种增长将持续进行，因此您应该考虑增加增长因子，以减少影响性能的事件的数量。

如果您的日志文件每天都在缩小，这种增长是重复的，这意味着如果您将日志增长到一个合理的大小，它就不会每天增加日志文件大小。停止缩小日志文件的进程，并手动将日志文件增长到适当的大小，以减少高频日志增长事件。

Answer 2

请花点时间想一想为什么会发生这些分配。一旦当前保存的信息不再需要时，SQL Server的日志将被设计为重复使用磁盘空间。这为您的案例提供了一些方案。

也许日志磁盘空间不是为了重用而释放的。如果数据库处于完全恢复模式，并且不采用日志备份，则这是可能的。如果没有日志备份，Server将在日志文件中保留过去的事务日志( files )数据，以便从故障中恢复。一旦日志备份已经完成，Server“知道”过去的日志数据在备份存储库中是安全的，它可以释放相应的磁盘空间供重用。如果您处于完全恢复状态，并且没有进行日志备份，则应该这样做。让它们足够频繁地与你的RPO相匹配。每15分钟一次并不少见。

它可能是事务日志文件正在缩小。在自动增长事件期间，Server从操作系统(OS)请求磁盘空间，并将该空间添加到t-日志中。在收缩事件期间，会发生相反的情况，Server会将其保留的部分磁盘空间交给OS。如果您正在收缩t-log文件，请停止此操作。这是不言而喻的，空间是需要的，所以不应该退还给操作系统。

您可能真的有更多的数据每天需要额外的t日志空间来处理。因此，t日志文件必须展开以容纳该数据。那么，您的建议，扩大文件和增加自动增长增量是有意义的。然而，还有一种选择。

与其在单个事务中处理所有数据，不如将其分批处理。每一批将是它自己的事务，并使用一些t日志磁盘。当事务提交时，t-log空间可供下一批处理使用(在简单恢复中)，也可以通过进行t-log备份(在完全恢复时)使用。在您的8am流程中的开发复杂性与控制t日志大小之间有一种权衡。这是由你的管理层和用户同意的。

有大量的信息和进一步的链接这里。

Answer 3

这里的正确解决方案是调整日志文件的大小，使自动增长不会频繁触发吗？在调整db日志文件之后，是否也应该将自动增长大小更改为类似500 db，以便在日志文件达到最大文件大小时至少限制自动增长事件的数量？

是的，根据应用程序工作负载的不同，您可以更改自动增长设置以适应日志中更多的操作空间，它不能保证(特别是当RECOVERY = FULL)阻止自动增长的火灾频率，这取决于日志文件截断，而日志文件截断只能在日志备份时发生。也就是说，在使用500MB的特定时间日志大小时，如果没有执行截断(日志备份)，则服务器尝试将其增加到1000 MB。

除了自动增长设置之外，您可能还需要关注日志备份计划。