当 MAXDOP 设置为 1 时，INDEX 重建如何并行进行

Question

我使用 SQL Server 2008R2 标准版实例（最近迁移到 Azure VM）的数百个数据库的 SharePoint 数据存储定期遇到 THREADPOOL 等待问题。它一次在许多（可能是所有）这些数据库中运行一个名为 proc_DefragmentIndices 的存储过程。

存储过程无条件地重建数据库中的每个索引。当然，它们是头部阻塞器（因为它是标准版，每个 ALTER INDEX 命令都以 ONLINE=OFF 运行）。因为一次运行的程序太多（每个都在不同的数据库中），并且它们并行运行（这会占用更多的工作人员），所以一切都堆积如山。只是为了增加噪音，Azure Backup 正在备份许多数据库，而这一切都在进行，消耗了更多的工作人员。活动监视器显示 106 个等待任务，以及许多 ALTER INDEX 命令的同一会话 ID 的多个实例（这就是我说它们并行的原因）。

我觉得令人困惑的是，即使实例中的 MAXDOP 设置为 1，这些 ALTER INDEX 语句也会并行运行，这是对 SharePoint 数据库的建议，并且由存储过程执行的 ALTER INDEX 语句没有使用 MAXDOP 选项来覆盖它.

Q1：当 MAXDOP 设置为 1 时，INDEX 重建如何并行？

Q2：活动监视器显示 ALTER INDEX 命令，但 sp_WhoIsActive 没有。有谁知道为什么？

Answer 1

它一次在许多（可能是所有）这些数据库中运行一个名为 proc_DefragmentIndices 的存储过程。

存储过程无条件地重建数据库中的每个索引。

我假设您对此没有任何控制权，但如果我不建议您尽快停止发生这种情况，我将是失职 使用 Ola Hallengren 的脚本，该脚本将仅在特定碎片时进行列表重建或重组阈值。或者考虑避免索引重建以支持统计更新。

当 MAXDOP 设置为 1 时，INDEX 重建如何并行？

他们不应该。而且它们真的不应该是因为您使用的是标准版 - 并行索引操作是企业版的一项功能。我想知道它在活动监视器中的显示方式是否有什么奇怪的地方。

活动监视器显示 ALTER INDEX 命令，但 sp_WhoIsActive 不显示。有谁知道为什么？

这是另一个危险信号，表明这里有些事情发生了。索引重建应该在sp_WhoIsActive. 这是我在笔记本电脑上重建 Posts 表（来自 StackOverflow2010 示例数据库）：

USE StackOverflow2010;

ALTER INDEX PK_Posts__Id ON dbo.Posts REBUILD;

作为进一步的调查点，sys.dm_os_tasks当您看到这些ALTER INDEX会话中的一个似乎已经并行时，您可以直接查询，以更加确定它是应该是串行的还是并行的。