我设置了三个维护计划以在 Sql Server 2005 实例上运行：
- 每周数据库优化，然后进行完整备份
- 每日差异备份
- 每小时事务日志备份
每小时的日志备份通常在几百 Kb 到 10Mb 之间，具体取决于活动级别，到周末的每日差异通常会增长到 250Mb 左右，每周备份大约是 3.5Gb。
我遇到的问题是，完整备份之前的优化似乎导致下一个事务日志备份增长到完整备份大小的 2 倍以上，在本例中为 8Gb，然后才恢复正常。
除此之外BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY，还有什么方法可以减少该日志备份的大小，或者完全阻止优化记录在事务日志中，因为它们肯定会在它们之前的完整备份中得到考虑？
这里有一些有趣的建议，似乎都表明对日志备份的工作方式存在误解。日志备份包含自上次日志备份以来生成的所有事务日志，无论在此期间进行了哪些完整或差异备份。停止日志备份或转向每日完整备份不会影响日志备份大小。唯一影响事务日志的是日志备份，一旦日志备份链启动。
此规则的唯一例外是日志备份链已中断（例如，通过进入简单恢复模型、从数据库快照恢复、使用 BACKUP LOG WITH NO_LOG/TRUNCATE_ONLY 截断日志），在这种情况下，第一个日志备份将包含自上次完整备份以来的所有事务日志 - 这将重新启动日志备份链；或者如果日志备份链尚未启动 - 当您第一次切换到 FULL 时，您将在一种伪 SIMPLE 恢复模型中操作，直到进行第一次完整备份。
要回答您最初的问题，无需进入简单恢复模型，您将不得不备份所有事务日志。根据您正在执行的操作，您可以更频繁地进行日志备份以减小它们的大小，或者执行更有针对性的数据库。
如果您可以发布有关您正在执行的维护操作的一些信息，我可以帮助您优化它们。您是否有机会进行索引重建，然后进行收缩数据库以回收索引重建使用的空间？
如果在维护期间数据库中没有其他活动，您可以执行以下操作：
希望这会有所帮助 - 期待更多信息。
谢谢
[编辑：在讨论完完整备份是否可以改变后续日志备份的大小（它不能）之后，我整理了一篇综合博客文章，其中包含背景材料和证明这一点的脚本。查看https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]
您可以缩小它们，但它们会再次增长，最终导致磁盘碎片。索引重建和碎片整理会产生非常大的事务日志。如果您不需要时间点可恢复性，您可以更改为简单恢复模式并完全取消事务日志备份。
我猜您正在使用维护计划进行优化，您可以将其更改为使用仅在达到某个碎片级别并且您不会受到任何性能影响时才执行索引碎片整理的脚本。这将生成更小的日志。
我会跳过每日差异，转而支持每日完整备份 BTW。
您的最后一个问题是：“除了 BACKUP LOG WITH TRUNCATE_ONLY 之外，还有什么方法可以减少该日志备份的大小，或者完全阻止优化记录在事务日志中，因为它们肯定会被完整地考虑在内备份他们之前？”
不，但这里有一个解决方法。如果您知道当时该数据库中的唯一活动将是索引维护作业，那么您可以在索引维护开始之前停止事务日志备份。例如，我在周六晚上的一些服务器，工作时间表是这样的：
这意味着我在晚上 9:45 到 11:30 之间没有时间点可恢复性，但回报是更快的性能。
简单的答案：更改您的每周优化工作，使其每晚以更平衡的方式运行。即在周日晚上重新索引表 ae，在周一晚上重新索引表等...找到一个很好的平衡，您的日志将大约是平均大小的 1/6。当然，如果您不使用内置的 ssis 索引维护作业，这种方法效果最好。
这样做的不利之处在于它对优化器和查询计划的重用造成严重破坏，这取决于您的数据库体验的负载。
但是，如果您只关心每周的 t-log 的大小，则将其每天或每小时拆分，并在其间运行 t-log 备份。
您还可以使用第三方工具（Quest 的 Litespeed、Red Gate 的 SQL Backup、Hyperbac）来减小备份和日志的大小。他们可以通过节省磁带快速收回成本。
您可以在数据库优化期间的各个时间点专门备份您的事务日志吗？t-logs 的总大小是相同的，但每个都会更小，可能以某种方式帮助你。
您能否进行更有针对性的数据库优化，从而创建更少的事务（有人提到这一点，但我不确定其含义是否已阐明）。比如容忍一定数量的碎片或浪费一段时间的空间。如果 40% 的表只有 5% 的碎片，那么不碰它们可以节省相当多的活动。
可以假设您的“优化”包括索引重建。在不会遇到大量更新和插入的数据库上，仅每周执行这些任务可能是可以接受的，但是如果您的数据高度流动，您可能需要做几件事：
如果您的日程安排允许并且影响可以接受，则每晚重建或重组您的索引。在执行这些夜间索引维护任务时，仅针对那些碎片超过 30% 用于重建和 15-30% 用于重组的索引。
这些任务是记录事务，所以如果您担心日志增长，那么我会提倡 Paul 推荐的内容。索引维护之前的最终事务日志备份，切换到简单恢复，然后进行维护过程，然后切换回完全恢复，然后进行完全数据备份应该可以解决问题。
我对我的日志文件采取了一种类似禅宗的方法：它们是它们想要的大小。只要与我所信奉的数据库活动相比，他们没有因为糟糕的备份实践而经历异常增长。
至于执行自由索引维护的脚本，请在线查看：那里有很多。大约一年前，Andrew Kelly 在 SQL Magazine 上发表了一篇不错的文章。SQLServerPedia 有一些来自 Michelle Ufford 的脚本，最新一期的 SQL 杂志（我相信是 2009 年 7 月）也有关于该主题的完整文章。重点是找到一个适合您的，并通过最少的自定义使其成为您自己的。