SQL Server 2016 SP2 - 在线重建死锁本身 - 这是一个错误吗？

Question

ALTER INDEX [PK_Order_Line_Inventory] 
ON [OrderManager_C].[Order_Line_Inventory] REBUILD 
WITH ( ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION= 5, ABORT_AFTER_WAIT=SELF) )

SPID 58 中的 3 个线程满足了这一点。但是，在争论同一个数据页时，其中一个线程成为死锁受害者。进程 ID 不同，执行上下文 ID 和 Txn 属性也不同。对于同一个命令，实际上有两个死锁，一个用于 3 个线程，第二个用于幸存的 2 然后成为一个。

SQL 2017在线索引操作指南中有这样一段，“虽然不常见，但在线索引操作在与数据库更新交互时会因为用户或应用程序活动而导致死锁。在这些罕见的情况下，SQL Server 数据库引擎会选择用户或应用程序活动是死锁受害者。 ”，但由于死锁涉及“本身”，我的根本原因没有找到。

该表只有一个单列、bigint、Clustered PK，在 520MB 中包含 2.7M 行；在 1::0/1 关系中对其父级的一个 FK。

出现问题：

1. 这是一个错误吗？我已经十多年没有在 SQL Server 上看到这种行为了。
2. REBUILD 中的任何一个存活下来了吗？
3. 这种情况有可能复发吗？
4. 我想我可以增强我们的碎片整理工具，以允许选择将特定表的 MAXDOP=4 覆盖为 =1，但这真的有必要吗？

我一直在寻找类似的事件，但是从 SQLCoffee 到 MS KB978250 的一个看起来很有希望的链接遇到了 404 错误，并且从搜索 MS（原始线程）中根本没有命中。该 KB 谈到了对 SQL2008 的修复 - 如果相关，人们会认为它仍然应该是 2016 位的修复......

任何人都可以对此有所了解吗？

图表：在 OneDrive 上

Answer 1

听起来像是查询内并行死锁。

它们通常被认为是错误，因为除了重新运行查询或降低语句的 maxdop（如果它经常发生在同一查询中）之外，您对此无能为力。

以下是一些有助于解决问题的信息，希望对您有所帮助。

https://support.microsoft.com/en-us/help/4089473/better-intra-query-parallelism-deadlock-troubleshooting-in-sql-server2