完整备份后，如何减less事务日志备份大小？

这里有一些有趣的build议，这似乎都表明了日志备份工作方式的误解。 日志备份包含自上次日志备份以来生成的所有事务日志，而不pipe在此期间进行的是全备份还是差异备份。 停止日志备份或转移到每日完整备份将不会影响日志备份大小。 一旦日志备份链启动，影响事务日志的唯一事情就是日志备份。

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

要回答你原来的问题，不用进入SIMPLE恢复模式，你将不得不备份所有的事务日志备份。 根据您所采取的操作，您可以采取更频繁的日志备份来减小其大小，或者执行更具针对性的数据库。

如果你可以发布一些关于维护操作的信息，我可以帮你优化它们。 你是否有任何机会做索引重build，然后收缩数据库来回收索引重build所使用的空间？

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

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

希望这有助于 – 期待更多的信息。

谢谢

[编辑：在所有讨论完全备份是否可以改变后续日志备份的大小（不能））后，我把一个全面的博客文章与背景材料和脚本，certificate了它。 查看http://www.sqlskills.com/BLOGS/PAUL/post/Misconceptions-around-the-log-and-log-backups-how-to-convince-yourself.aspx%5D

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

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

我会跳过每日差异，转而支持每日完整备份。

你最后的问题是： “除了BACKUP LOG WITH TRUNCATE_ONLY之外，有没有什么办法可以减less日志备份的大小，或者根本没有把最优化logging在事务日志中，因为它们肯定会占满他们先前的备份？“

不，但是这是一个解决方法。 如果您知道当时该数据库中的唯一活动将是索引维护作业，则可以在索引维护开始之前停止事务日志备份。 例如，周六晚上的一些服务器，工作时间表如下所示：

• 晚上9:30 – 事务日志备份运行。
• 9:45 PM – 事务日志备份最后一次运行。 时间表在9:59停止。
• 10:00 PM – 指数维修工作开始，并在11:30之前完成内置停车。
• 下午11:30 – 完整备份作业开始，并在30分钟内完成。
• 上午12:00 – 事务日志备份每15分钟重新启动一次。

这意味着我在9点45分到11点30分之间没有时间点可恢复性，但是回报是更快的performance。

简单的答案：改变你的每周优化工作，以更均衡的方式在夜间运行。 即周日晚上重新索引表格，星期一晚上重新索引表格……find一个好的平衡点，你的日志平均大概是1/6的大小。 当然，如果你不使用内置的ssis索引维护工作，这个效果最好。

这个不利的一面，这是很重要的，这取决于你的数据库经验的负载是它破坏了优化器和重用查询计划。

但是如果你关心的只是每周的t-log的大小，那就把它分成每天或者每小时，然后在两者之间运行t-log备份。

您还可以查看第三方工具（来自Quest的Litespeed，来自Red Gate的SQL备份，Hyperbac）以减less备份和日志的大小。 他们可以通过节省成本的方式快速付款。

您可以在数据库优化期间的各个点上特别备份您的事务日志吗？ t日志的总大小将是相同的，但每一个会更小，可能在某种程度上帮助你。

你可以做更多有针对性的数据库优化，减less交易创build（有人提到这一点，但我不确定这些影响被拼写出来）。 比如容忍一定的碎片或浪费一段时间的空间。 如果你的桌子的40％只有5％分割，而不触摸它们可以节省相当多的活动。

你可以每天在差分（或全部）之前或之后进行优化，所以在最后一次而不是最后一次优化1天时，可以优化吗？

你可以在每个差异之前或之后做七分之一的优化（也许是由表格分解），这样每个星期所有的优化都会循环一次吗？

可以认为你的“优化”包括索引重build。 只有在每周执行这些任务的情况下，对于不会遇到大量更新和插入的数据库来说，这是可以接受的。但是，如果数据stream畅性高，则可能需要执行以下操作：

1. 如果您的日程安排允许，并且影响是可以接受的，则每晚重build或重新组织索引。 在执行这些夜间指数维护任务时，只针对那些超过30％重build的索引，重组的范围在15-30％。

2. 这些任务是logging事务，所以如果你关心日志增长，那么我会主张保罗所build议的。 索引维护之前的最终事务日志备份，切换到简单恢复，然后是维护过程，然后切换回完全恢复，然后完全数据备份应该做的伎俩。

我对我的日志文件采取类似禅宗的方法：它们是他们想要的大小。 只要他们没有忍受由于备份做法差而导致的exception增长，而不是数据库活动，这是我生活的口头禅。

至于执行酌情索引维护的脚本，可以在网上查看：这里有很多。 大约一年前，Andrew Kelly在SQL杂志上发表了一篇不错的文章。 SQLServerPedia有一些来自Michelle Ufford的脚本，最新一期的SQL杂志（我相信2009年7月）也有关于这个话题的完整文章。 要点是find一个适合你的工具，并以最less的自定义设置为你自己。