如何在完全备份之后减少事务日志备份大小？

Question

为了在Server 2005实例上运行，我设置了三个维护计划：

• 每周进行数据库优化，然后进行完全备份
• 每日差动备份
• 每小时事务日志备份

根据活动级别，每小时日志备份通常在几百Kb至10 Kb之间，到一周结束时，日差值通常增加到250 Kb左右，每周备份大约为3.5Gb。

我遇到的问题是，在完全备份之前的优化似乎导致下一个事务日志备份增长到完全备份大小的2倍以上，在本例中为8Gb，然后才恢复正常。

除了BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY之外，是否有任何方法可以减少日志备份的大小，或者根本防止在事务日志中记录优化，因为它们肯定会在它们之前的完整备份中得到考虑？

Answer 1

这里有一些有趣的建议，这些建议似乎都显示了对日志备份工作方式的误解。日志备份包含自上一次日志备份以来生成的所有事务日志，无论在此期间进行什么完整备份或差异备份。停止日志备份或移动到每日完整备份对日志备份大小没有任何影响。一旦日志备份链启动，影响事务日志的唯一因素就是日志备份。

此规则的唯一例外是日志备份链已经中断(例如，通过转到简单恢复模型，从数据库快照中恢复，使用备份日志截断日志而不使用_ log /TRUNCATE_ only )，在这种情况下，第一个日志备份将包含自上次完全备份以来的所有事务日志--这将重新启动日志备份链；或者如果日志备份链尚未启动--当您第一次切换到完全备份时，您将在一种伪简单恢复模型中操作，直到第一个完整备份被执行。

为了回答您最初的问题，在不进入简单恢复模型的情况下，您将不得不吸收所有事务日志的备份。根据您正在执行的操作，您可以采取更频繁的日志备份来缩小它们的大小，或者执行更有针对性的数据库。

如果你可以发布一些关于你正在做的维护操作的信息，我可以帮助你优化它们。您是否有可能在索引重新构建之后再进行收缩数据库，以重新获取索引重新构建所使用的空间？

如果在进行维护时数据库中没有其他活动，则可以执行以下操作：

• 确保停止用户活动
• 进行最后的日志备份(这使您可以恢复到维护的起始点)
  • 切换到简单恢复模型
  • 执行维护-日志将在每个检查点上截断。
  • 切换到完全恢复模式，并进行完全备份
  • 照常继续

希望这有帮助-期待更多的信息。

谢谢

编辑:在讨论了一个完整的备份是否可以改变后续日志备份的大小(它不能)之后，我把一篇完整的博客文章和背景材料以及一个证明它的脚本放在一起。去[https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]看看吧

Answer 2

您可以缩小它们，但它们只会再次增长，最终导致磁盘碎片。索引重建和碎片整理会产生非常大的事务日志。如果您不需要实时恢复功能，则可以更改为简单的恢复模式，并完全取消事务日志备份。

我猜您正在使用维护计划进行优化，您可以将其更改为使用一个脚本，该脚本只有在达到某个碎片级别时才会执行索引碎片整理，而且您可能不会受到任何性能的影响。这将生成小得多的日志。

我会跳过每日差异，以支持每日全面备份BTW。

Answer 3

您的最后一个问题是：“除了使用TRUNCATE_ONLY备份日志之外，是否有任何方法可以减少日志备份的大小，或者根本防止在事务日志中记录优化，因为它们肯定会在它们之前的完整备份中得到考虑？”

不，但这里有个解决办法。如果您知道当时数据库中唯一的活动将是索引维护作业，那么您可以在索引维护开始之前停止事务日志备份。例如，星期六晚上我的一些服务器，作业计划如下所示：

• 晚上9:30 -事务日志备份运行。
• 下午9:45 -事务日志备份最后一次运行。时刻表在9:59停止。
• 10:00下午10:00-索引维护工作开始，并有内置停止完成11:30之前。
• 下午11:30 -完全备份作业开始并在30分钟内完成。
• 上午12:00 -事务日志备份每15分钟重新启动一次。

这意味着我没有在晚上9:45到11:30之间的实时恢复能力，但回报是更快的性能。