usr*_*usr 5 index sql-server maintenance sql-server-2008-r2 fragmentation
我考虑安排每晚重新组织所有表的 SQL Server 作业。我们没有企业，所以我们不能在线重建（这意味着我们需要重组）。我们也不想在碎片化和空间维护上投入太多时间，因此我们正在寻求一种可以快速实施且未来不需要进一步时间投入的解决方案。
对恢复的生产备份的测试表明，在减少碎片和重新获得空间方面，重组几乎与重建一样好。
这是一个合理的想法吗？该方案是否会导致可用性或可维护性问题？这是一个合理的长期解决方案吗？
有更好的方法 - 每晚重新组织所有索引可能会非常浪费。为什么还要费心重组一个 12% 碎片化的索引呢？如果需要 30 分钟，而您只减少 2% 或 3% 的碎片，为什么要每晚重新组织一个 10GB 的索引？无论如何，您应该花费多少精力来重新组织大部分或完全在内存中的索引 - 确保节省一些磁盘空间，但您必须将索引从缓冲区中拉出才能这样做 - 节省的空间是否值得导致性能下降?
有一些免费的脚本可以帮助您做出这些决定，而且很容易覆盖默认值：
SentryOne 还有一个名为SQL Sentry的工具（不是免费的），它通过提供完整的历史报告、广泛到细粒度的规则和计划来重新组织/重建哪些索引以及何时（从服务器范围到单个索引和甚至分区）、对并发操作的支持（如果您的维护窗口很紧）、用于调度的拖放日历，以及准确评估您正在做的工作如何影响性能的能力。