索引重建需要时间导致超时答案

【问题标题】：Index Rebuild Takes Time Causing Timeouts索引重建需要时间导致超时
【发布时间】：2017-08-03 05:09:35
【问题描述】：

我们使用的是 SQL Server 标准版 (AWS RDS)。

我们正在使用Ola Hallengren的索引重建工具。

此重建代理作业需要时间导致超时。

我们将这项工作分为两个，第一个包含对一个大表的重建，另一个包含对其他数据库表的重建。这些安排在不同的时间。

第一项工作（用于重建单个大表）是导致问题的原因。

有人可以提出一些解决问题的方法吗？

【问题讨论】：

您多久进行一次重建？为什么表的索引是碎片化的？重建索引时看到的等待类型有哪些？
请准确地说，是重建索引超时还是导致表脱机而您称之为“超时”的工作？
如果您说您的表长时间处于离线状态，并且由于您处于标准状态，因此您无法使用在线重建，您的选项是 REORGANIZE
@PrebenHuybrechts 我们的重建工作每天都在运行。它还更新统计信息。此重建作业有时需要大约 15 分钟。该表是高度事务性的，即它每天观察许多插入和更新。可能是导致碎片化。
@sepupic 当这个重建作业正在运行并且我们尝试在此期间查询表时，我们得到超时错误。

【解决方案1】：

由于ONLINErebuild 不适合您（仅限企业版并且您使用的是标准版），所以ALTER INDEX..REORGANIZE 是您的选择。

重组索引使用最少的系统资源。它进行碎片整理表上的聚集和非聚集索引的叶级和通过对叶级页面进行物理重新排序以匹配叶节点的逻辑，从左到右的顺序。重组也压缩索引页。压实基于现有填充因子值。

这不是离线操作，它只会阻止它正在处理的页面，它不会作为一个事务执行（离线重建在 1 个事务中完成），您可以在需要时中断它。完成的工作不会丢失，下次执行 REORGANIZE 时，它会从之前停止的点开始：

重组：此选项更轻量级。它穿过叶子索引的级别，并且随着它修复页面的物理顺序并且还压缩页面以应用任何先前设置的填充因子设置。此操作始终在线，如果取消则它能够停在原地（它没有巨大的操作回滚）。

【讨论】：