Gab*_*abe 27 index sql-server sql-server-2012
我们正在讨论是否对 DW 表使用 SORT_IN_TEMPDB 选项。我的理解是，使用此选项时会有更多的写入，尽管它们更具顺序性。我们有一个 SAN（它有时非常慢），所以在我们的例子中，我们希望尽可能地限制写入次数。我相信 tempdb 位于单独的 LUN（磁盘集）上。
我们的数据文件和 tempdb 文件中有足够的磁盘空间。在这种情况下，我们会从使用 SORT_IN_TEMPDB 中受益吗？
让我印象深刻的一件事是对这个答案的评论
重建索引时，您需要两倍于索引的空间 + 20% 用于排序。因此，一般而言，要重建数据库中的每个索引，您只需要数据库中最大索引的 120%。如果你使用 SORT_IN_TEMPDB，你只赢了 20%，你的数据文件中仍然需要额外的 100%。此外，在 tempdb 中使用 sort 会大大增加您的 IO 负载，因为不是将索引一次写入数据文件，而是现在将其写入一次 tempdb，然后将其写入数据文件。所以这并不总是理想的。
我们绝对不想通过慢速/可能配置错误的 SAN 增加 IO 负载。
测试这个的最佳方法是什么？通过简单地重建带有和不带有选项的表并记录时间？
编辑：我们有 8 个 tempdb 文件，每个 15GB。我们确实设置了 TF 1117/1118 标志并启用了 IFI。我们目前混合使用 sort_in_tempdb 选项和不使用它进行重建。
谢谢！
SQL Server 2012 企业版
Kin*_*hah 28
SORT_IN_TEMPDB意味着 SQL Server 将用于tempdb分配临时空间，而不是在正在重建索引的用户数据库中分配空间。这意味着在索引重建操作期间您将需要较少的用户数据库可用空间，而在 tempdb 中需要更多可用空间。
当 tempdb 位于与用户数据库不同的一组磁盘 (LUN) 上时，它可为您提供更好的优势。
如果SORT_IN_TEMPDB 选项设置为 ON 并且 tempdb 位于与目标文件组不同的一组磁盘上，则在第一阶段，数据页的读取发生在与 tempdb 中排序工作区的写入不同的磁盘上。这意味着数据键的磁盘读取通常会在整个磁盘上以更连续的方式继续，并且对 tempdb 磁盘的写入通常也是串行的，构建最终索引的写入也是如此。即使其他用户正在使用数据库并访问单独的磁盘地址，当指定 SORT_IN_TEMPDB 时，读取和写入的整体模式也比不指定时更有效。
确保在 SORT_IN_TEMPDB 为 ON 时阅读磁盘空间要求。
慢/可能配置错误的 SAN
你知道痛点。为什么不与您的 SAN 管理员合作来修复它？配置错误或速度慢的 SAN 会导致各种问题，例如速度慢。
需要注意的一些要点：
测试这个的最佳方法是什么？
是的，你必须对它进行测试分析WAITSTATS当你有和没有重建索引SORT_IN_TEMPDB。还要测量运行时间，在 PROD 中执行时，请确保在维护窗口或较少的服务器活动期间执行此操作。还要检查您的读/写数据和日志延迟。
我不确定您是否有Instant file initialization，但它会在恢复、数据文件自动增长和创建新数据库时受益（只是为了完整性而提及）。