我正在寻求一些建议。我必须重建我的数据库索引（因为缩小），但由于磁盘空间不足，我不确定哪种恢复模式更好，以避免出现磁盘空间不足错误以增加日志文件的大小。请帮助我在简单或批量日志恢复模式之间进行选择。
AskOverflow.Dev
我正在寻求一些建议。我必须重建我的数据库索引（因为缩小），但由于磁盘空间不足，我不确定哪种恢复模式更好，以避免出现磁盘空间不足错误以增加日志文件的大小。请帮助我在简单或批量日志恢复模式之间进行选择。
收缩是一种浪费的操作。. 诸如索引重建之类的索引维护也是一种浪费的操作。. 重建索引会在数据文件中产生大量未使用的分配空间。索引碎片在性能方面毫无意义。如您所见，缩小数据库会导致高水平的索引碎片。这是一个恶性循环，就像布伦特在我链接的第一篇文章中提到的那样。我的建议，不要这样做（除了非常罕见的情况）。
但是，如果您仍然对重建索引感到困惑，那么使用简单恢复模型这样做至少会最大限度地减少您在该过程中的事务日志中的日志记录。但是，它不会为您节省数据文件中的任何空间。问题是通过切换到简单恢复模式，您会在上次完整备份后失去时间点恢复，因此在下一次完整备份之前存在数据丢失风险。在切换回完全恢复模式并进行完全备份之前，您将无法使用时间点恢复。如果您的恢复点目标可以容忍这一点，那很好。
您可以使用一些功能来重建索引，这可能有助于您的事业。
如果您的 TEMPDB 位于专用磁盘上，则可以尝试使用 TEMPDB 运行索引重建。此外，您可以通过在运行索引优化时限制页数来从小到大工作。
您可以为此使用 OLA hallengren 的工作。 https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
使用 OLA Hallengren 时，我还建议单独更新统计信息。至于恢复模式，我不确定它是否重要。
我相信关于碎片化的普遍共识，超过 5% 建议重组，超过 30% 则应该重建。