>每周数据库优化,然后进行完整备份
>每日差异备份
>每小时事务日志备份
每小时日志备份通常在几百Kb到10Mb之间,具体取决于活动级别,每周差异通常在一周结束时增长到大约250Mb,每周备份大约为3.5Gb.
我遇到的问题是完全备份之前的优化似乎导致下一个事务日志备份增长到完整备份大小的2倍,在这种情况下为8Gb,然后才恢复正常.
除了BACKUP LOG< DatabaseName> WITH TRUNCATE_ONLY,是否有任何方法可以减少日志备份的大小,或者防止优化记录在事务日志中,因为它们肯定会在它们之前的完整备份中被考虑？
解决方法
此规则的唯一例外是日志备份链已被破坏(例如,通过转到SIMPLE恢复模型,从数据库快照恢复,使用BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY截断日志),在这种情况下,第一个日志备份将包含自上次完全备份以来的所有事务日志 – 重新启动日志备份链;或者如果还没有启动日志备份链 – 当您第一次切换到FULL时,您将使用一种伪SIMPLE恢复模型,直到进行第一次完整备份.
要回答原始问题,而不进入SIMPLE恢复模型,您将不得不提取备份所有事务日志.根据您正在执行的操作,您可以更频繁地进行日志备份以减小其大小,或者执行更具针对性的数据库.
如果您可以发布有关您正在进行的维护操作的一些信息,我可以帮助您优化它们.您是否有机会进行索引重建,然后使用收缩数据库来回收索引重建所使用的空间？
如果在发生维护时数据库中没有其他活动,则可以执行以下操作：
>确保用户活动已停止
>进行最终日志备份(这使您可以恢复到维护点开始)
>切换到SIMPLE恢复模型
>执行维护 – 日志将在每个检查点上截断
>切换到FULL恢复模型并进行完整备份
>继续正常
希望这会有所帮助 – 期待更多信息.
谢谢
[编辑：在关于完整备份是否可以改变后续日志备份的大小的讨论之后(它不能)我将一个综合的博客文章与背景材料和证明它的脚本放在一起.请在http://www.sqlskills.com/BLOGS/PAUL/post/Misconceptions-around-the-log-and-log-backups-how-to-convince-yourself.aspx]查看
