SQL 重建索引、恢复模型和数据库日志文件大小？

Question

我有一个数据库，我们目前全天运行事务日志备份，准确地说是每 30 分钟一次，我们每天凌晨 2 点运行一次完整备份。

每个星期六凌晨 3 点，我们都有一个作业设置来重建所有表上的索引。

话虽如此，进行索引重建会导致我们的事务日志大幅增长。我正在考虑不同的想法来减少所需的额外驱动器空间（重新索引后大约 25GB）。

我正在考虑在重建任务之前将数据库恢复模型设置为简单，以防止记录所有索引重建，然后在重建完成后将其设置回完整。

还有其他人使用这种方法吗？或者任何人都可以提供有关为什么这可能是一个坏主意的见解/建议？或者关于如何在执行数据库维护任务时处理巨大日志文件的任何提示？

Answer 1

切换到 SIMPLE 意味着你打破了日志链。当您“恢复”到 FULL 时，您需要启动一个新的日志链，这意味着您必须进行完整备份并再次开始进行新的日志备份。切换到简单，无论多短，实际上都会在您的备份链中创建一个新的“时代”，因为从切换到简单之前的任何备份都不能再应用于切换后的数据库，反之亦然。

因此，此时您必须停下来思考：使您拥有完整恢复模型的业务需求是什么？不管是什么原因，它不太可能在每周六凌晨 3 点“暂停”，也不太可能容忍你可以从周五到周四及时恢复的“时代”情况，但你不能从周六开始到星期五，因为星期六是一个新的“时代”。换句话说，如果您对 FULL 恢复模型有业务需求，那么最好不要破坏它。

但是，如果您对 FULL 恢复模型没有业务需求，那么您就有发挥的空间。我并不是要切换到 SIMPLE，我的意思是使用“其他”恢复模型：BULK_LOGGED。您的重新索引操作生成大量日志的原因是它们发生在完整恢复模式下。在 BULK_LOGGED 下，索引重建（离线和在线）将使用最少记录的操作，请参阅可以最少记录的操作：

如果数据库设置为简单或大容量日志恢复模式，则无论是离线还是在线执行操作，都会最少记录一些索引 DDL 操作。最少记录的索引操作如下：

• CREATE INDEX 操作（包括索引视图）。
• ALTER INDEX REBUILD 或 DBCC DBREINDEX 操作。
• DROP INDEX 新堆重建（如果适用）。

因此，如果可能，请将数据库恢复模型切换为 BULK_LOGGED 并保持原样。

Answer 2

这里有很多考虑因素：

• 简单或完整，相同的数据将被写入事务日志。不同之处在于，在简单恢复中，日志将在操作之间被截断，您需要完整备份日志以释放日志空间以供重新使用。
• 一两个表可能是造成大部分碎片的原因。如果是这种情况，您可能会发现无论恢复模式如何，日志都会增长到相似的大小。
• 您已确定该数据库需要完全恢复。您能否冒着切换到简单、出现问题且无法进行时间点恢复的风险？
• 您的维护过程会生成 25GB 的日志。在最先进的、直接付费的 SAN 阵列中，这并不是您需要的昂贵的磁盘块。

我过去采取的一种方法是将日志备份合并到重新索引/重建脚本中。在处理每个表之前记录日志大小和空闲百分比，然后检查空闲百分比和大小。如果可用空间少于 x%，或者日志发生增长，请备份日志。