当前备份大小的主要问题 – 我已经经历了很多问题，但是发现了冲突的情况。 我有多个数据库相同的问题，但使用一个作为例子，这里是一个备份文件（26.2GB）的组件：
我每6小时备份一次事务日志，这是一个约6个数据库，驱动一个合理的高容量的Web应用程序。 每个星期天我们重build索引，似乎每次发生，事务日志上升了5％。 而且，事务日志的备份也没有减less太多。
系统需要在备份之间进行时间点恢复的能力，而且重build索引似乎使得事务日志的大小跃升起来，我并没有真正看到备份索引或保存在索引中的主要好处给定的事务日志可以build立在恢复之上。 这可以放过吗？
最终，我正在寻找非常低的事务日志备份大小，以便于操作使用，从而简化了备份间的时间点恢复。 我不认为我想在我的事务日志中有索引，而且我没有对他们在我的备份文件中感到恼火 – 这是天真的吗？ 另外我想知道如何更好地pipe理交易日志的大小 – 我是否应该更经常地支持它，是否有一个它不会减less的原因？
我可能在这里忽略了这个观点或寻找乌托邦，但现在我迫切需要这个策略的帮助！
编辑：不知道是否有任何区别，但数据库镜像是活动的，所有备份等在主体上执行。
您对事务日志中的内容没有这种细粒度的控制。 您可以在FULL和BULKINSERT模式之间来回翻转。 但是，有风险，这是你需要pipe理的另一件事情，我不会这样做。
备份事务日志不会缩小事务日志的大小。 您可以手动收缩事务日志。 反复的增长/缩减周期往往会使文件分割，因为性能的负面影响，所以不build议这样做。
如果你想控制日志备份的大小，我build议你：
比每六小时更频繁地执行日志备份。 这会给你更多的文件，但他们应该平均更小。 我以完整模式运行的大多数系统每隔几分钟就有一次日志备份。 如果您有自动处理日志备份的方式，文件数量的增加不应该是一个问题。 请注意，您可以为SQL代理作业设置多个计划。 例如，您可以指定一个事件缓慢的每六小时一次的事件日志备份，以及事情很繁忙时的每十分钟一次。
看看压缩你的备份文件。 一些最新版本的SQL Server具有内置的备份文件压缩function，您可以随时使用SQL Lightspeed等第三方产品。