遇到意外增长事务日志文件大小

Question

我们使用的是SQL Server 2008 R2标准版，我们创建了维护计划Rebuild Index, Reorganized Index and update Statistic，每天凌晨 1 点安排。执行此维护计划后，数据库事务日志文件大小异常增加。假设，如果主数据文件为 7 GB，则事务日志文件将增长到 55 GB。

如何在没有收缩过程的情况下减小事务日志文件的大小（因为它不好 – 增加碎片 – 降低性能）

推荐的另一种解决方案是完全备份后的事务日志备份。我们做了同样的事情并观察到文件大小没有变化，它显示的大小与主文件为 7 GB 和事务日志文件为 55 GB 之前的大小相同。

请建议我减少日志文件大小而不影响性能的最佳方法。

Answer 1

如何在没有收缩过程的情况下减小事务日志文件的大小（因为它不好 – 增加碎片 – 降低性能）

那不是真的。日志收缩是相当良性的，您正在考虑数据收缩。请参阅如何缩小 SQL Server 日志以了解其增长的原因、如何缩小它以及为什么是良性的。

我的第一个建议是使用智能索引维护计划。过度活跃的重建是昂贵的、有害的并且完全没有必要。许多人对Ola Hallengren 的索引维护脚本发誓。

您还必须考虑利用最少的日志记录。索引维护是最少日志操作的主要候选者，但您必须通过对数据库使用大容量日志恢复模型来启用它们。请参阅可以最少记录的操作：

如果数据库设置为简单或大容量日志恢复模式，则无论是离线还是在线执行操作，都会最少记录一些索引 DDL 操作。

Answer 2

• 1- 您可以通过更频繁地备份事务日志并将事务日志备份设置为每 15 分钟、24 x 7 运行一次，甚至在活动频繁时更频繁地运行，从而更好地控制增长。

• 2-在完全恢复模式下，所有批量操作都被完全记录。但是，您可以通过将数据库临时切换到批量操作的批量日志恢复模式来最大程度地减少一组批量操作的日志记录。最小日志记录比完整日志记录更有效，并且它减少了在批量事务期间大规模批量操作填充可用事务日志空间的可能性。但是，如果在最小日志记录生效时数据库损坏或丢失，则无法将数据库恢复到故障点。
• 3-使用脚本等单独的重建过程会更好地帮助您。这些可以更好地控制您的运行重建/重组方式。这是一个链接，可以帮助您处理您需要的脚本！