目前备份大小的主要问题 - 我遇到过很多问题，但发现情况相互矛盾。我有多个数据库存在同样的问题，但以其中一个为例，以下是备份文件 (26.2GB) 的组成部分：
- 数据 5GB
- 索引 1.2GB
- 交易日志 20GB
我每 6 小时备份一次事务日志，这是驱动大量 Web 应用程序的 6 个数据库中的 1 个。每个星期日我们都会重建索引，似乎每次发生这种情况时，事务日志都会增加 5%。此外，事务日志的备份并没有减少其大小。
系统需要能够在备份之间进行时间点恢复，而且重建索引似乎会使事务日志的大小猛增，我并不认为备份索引或将索引保存在事务日志中有什么好处，因为它们可以在恢复时构建。这可以规避吗？
最终，我正在寻找一个非常小的事务日志备份大小，用于操作使用，只需方便备份之间的时间点恢复。我不认为我想在事务日志中拥有索引，而且我也不介意它们在我的备份文件中 - 这是天真的吗？此外，我想知道如何更好地管理该事务日志的大小 - 我是否应该更频繁地备份它，它的大小没有减小的原因是什么？
我可能没有抓住重点，或者在寻找乌托邦，但我现在迫切需要这一策略的帮助！
编辑：不确定是否有任何区别，但数据库镜像是活动的，所有备份等都在主体上执行。
答案1
您无法对事务日志的内容进行这种精细控制。您可以在 FULL 和 BULKINSERT 模式之间来回切换。但是，这样做存在风险，您需要管理额外的事情，我不会这么做。
备份事务日志不会缩小事务日志的大小。您可以手动缩小事务日志。重复的增长/缩小周期往往会造成文件碎片，不建议这样做，因为这会对性能产生负面影响。
如果您想控制日志备份的大小，我建议您：
每六小时执行一次以上的日志备份。这样可以生成更多文件，但平均而言文件会更小。我以完整模式运行的大多数系统每隔几分钟就会进行一次日志备份。如果您有处理 tlog 备份的自动化方法，文件数量的增加应该不是什么大问题。请注意，您可以为 SQL Agent 作业设置多个计划。例如，当运行缓慢时，您可以指定每六小时进行一次 tlog 备份，当运行繁忙时，您可以指定每十分钟进行一次 tlog 备份。
考虑压缩备份文件。一些较新版本的 SQL Server 内置了备份文件压缩功能，您也可以使用 SQL Lightspeed 等第三方产品。