Server 2016 SP2 --联机重建DEADLOCKed本身--这是一个错误吗？

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 网上索引操作指南有一个段落，“虽然不常见，但由于用户或应用程序活动而与数据库更新交互时，联机索引操作会导致死锁。在这些罕见的情况下，Server数据库引擎将选择用户或应用程序活动作为死锁受害者。”但由于死锁涉及“自身”，因此找不到我的根本原因。

该表只有一个列，bigint，集群PK，包含520 PK中的2.7M行；一个FK以1:0/1的关系传递给它的父表。

出现了以下问题：

1. 这是个虫子吗？我在Server上已经有十多年没见过这种行为了。
2. 重建中有谁幸存下来了吗？
3. 这种情况有可能再次发生吗？
4. 我想我可以增强我们的Defrag工具，允许为特定的表将MAXDOP=4重写为=1，但这真的有必要吗？

我已经搜索过类似的事件，但是从SQLCoffee到MS KB978250的链接看起来很有希望，但是在搜索MS (原螺纹)时遇到了一个404错误，根本没有命中。这个知识库提到了SQL2008的一个补丁--如果相关的话，人们会认为它仍然应该是2016年比特中的一个补丁.

有人能解释一下这件事吗？

图：论单驱

Answer 1

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

它们通常被认为是bug，因为除了重新运行查询或删除语句的maxdop (如果它经常发生在相同的查询中)之外，您对它无能为力。

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

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