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

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

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

每小时的日志备份通常在几百Kb到10Mb之间，具体取决于活动的级别，到星期结束时，每日差异通常会增长到250Mb左右，每周备份约为3.5Gb。

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

除了之外BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY，是否有任何方法可以减小该日志备份的大小，或者完全不将优化记录在事务日志中，因为可以肯定的是，这些优化将在之前的完整备份中得到考虑？

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

该规则的唯一例外是日志备份链是否已断开（例如，通过转到SIMPLE恢复模型，从数据库快照还原，使用BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY截断日志），在这种情况下，是第一次日志备份将包含自上次完整备份以来的所有事务日志-重新启动日志备份链；或者，如果尚未启动日志备份链-首次切换为FULL时，您将以一种伪SIMPLE恢复模式进行操作，直到进行了第一次完全备份为止。

要回答您的原始问题，无需进入简单的恢复模型，您将不得不吸收所有事务日志的备份。根据您要执行的操作，您可以进行更频繁的日志备份以减小其大小，或者执行更多目标数据库。

如果您可以发布有关您正在进行的维护操作的信息，那么我可以帮助您进行优化。您是否有机会进行索引重建，然后执行收缩数据库来回收索引重建所使用的空间？

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

• 确保停止用户活动
• 进行最终日志备份（这使您可以恢复到维护开始为止）
  • 切换到SIMPLE恢复模型
  • 执行维护-日志将在每个检查点截断
  • 切换到完整恢复模型并进行完整备份
  • 照常继续

希望对您有所帮助-期待更多信息。

谢谢

[编辑：在讨论了完整备份是否可以改变后续日志备份的大小（不能这样做）之后，我整理了一篇综合性的博客文章，并提供了背景资料和能证明这一点的脚本。在https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/中进行检查]

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

我猜想您正在使用维护计划进行优化，您可以将其更改为使用仅在达到特定碎片级别并且不会遭受任何性能损失的情况下进行索引碎片整理的脚本。这将生成更小的日志。

我会跳过每日差异，转而使用每日完整备份BTW。

您的最后一个问题是：“除了使用TRUNCATE_ONLY的BACKUP LOG之外，还有没有其他方法可以减少该日志备份的大小，或者完全不将优化记录在事务日志中，因为可以肯定的是，它们将被全部计入。他们先备份吗？”

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

• 晚上9:30-运行事务日志备份。
• 晚上9:45-事务日志备份最后一次运行。日程安排在9:59停止。
• 晚上10:00-索引维护作业开始，并且内置停止作业在11:30之前完成。
• 晚上11:30-完整备份作业将在30分钟内开始并完成。
• 上午12:00-事务日志备份每15分钟重新开始一次。

这意味着我在晚上9:45到11:30之间没有时间点可恢复性，但是收益是更快的性能。

简单回答：更改您的每周优化工作，使其在夜间更均衡地运行。例如，在周日晚上重新索引表ae，在周一晚上重新加载表f等，...找到一个不错的平衡，您的日志平均大约是大小的1/6。当然，如果您不使用内置的sis索引维护作业，这将是最好的选择。

不利的一面是，它的负面影响很大，具体取决于您的数据库负载，这会给优化器和重用查询计划造成严重破坏。

但是，如果您关心的只是每周一次的t-log大小，则将其每天（每天）或小时（小时）分割，然后在它们之间运行t-log备份。

您可能还会研究第三方工具（Quest的Litespeed，Red Gate的SQL备份，Hyperbac）来减小备份和日志的大小。他们可以节省磁带以快速收回成本。

可以假定您的“优化”包括索引重建。在没有大量更新和插入的数据库上，仅每周执行一次这些任务可能是可以接受的，但是，如果您的数据流动性很高，您可能需要做几件事：

1. 如果您的日程安排允许并且影响可以接受，则每晚重建或重新组织索引。在执行这些夜间索引维护任务时，仅针对那些零散的索引（对于重建而言不超过30％，对于重组则在15％至30％范围内）。

2. 这些任务是已记录的事务，因此，如果您担心日志的增长，那么我会推荐Paul的建议。最终维护索引备份之前的事务日志，切换到简单恢复，然后进行维护过程，然后再切换回完全恢复，然后再进行完全数据备份，可以解决问题。

我对日志文件采取了类似zen的方法：它们就是想要的大小。只要与数据库活动（这是我赖以生存的口头禅）相比，由于备份操作不当，他们就无法承受异常的增长。

至于执行可随意调整的索引维护的脚本，请在线查看：那里有很多东西。大约一年前，安德鲁·凯利（Andrew Kelly）在《 SQL Magazine》上发表了一部不错的书。SQLServerPedia提供了Michelle Ufford的一些脚本，最新一期的《 SQL Magazine》（我相信是2009年7月）上也有关于该主题的全文。重点是找到最适合您的产品，并通过最少的自定义将其制成自己的产品。

您可以在数据库优化期间的各个时间点专门备份事务日志吗？t-log的总大小是相同的，但是每个t-log会更小，可能以某种方式帮助您。

您能否进行更多有针对性的数据库优化，以减少创建的事务（有人提到了这一点，但我不确定其中的含义是否明确）。例如忍受一定数量的碎片或浪费一段时间。如果40％的表只有5％的碎片，不触摸它们可以节省大量的活动。