为什么 SQL Server SET DEADLOCK_PRIORITY HIGH 不被兑现？答案

【问题标题】：Why would SQL Server's SET DEADLOCK_PRIORITY HIGH not be honored?为什么 SQL Server SET DEADLOCK_PRIORITY HIGH 不被兑现？
【发布时间】：2018-01-22 12:09:32
【问题描述】：

我已经捕获了一个 SQL Server 2012 死锁图（使用 Gail Shaw's 查询），该图显示了一个带有 taskpriority="10" 的进程被选为两个带有 taskpriority="0" 的进程的死锁受害者。

我的理解是首先检查死锁优先级，优先级较低的进程将被选为牺牲品。只有当所有进程的优先级相同时，其他因素才会相关。谁能解释为什么 DEADLOCK_PRIORITY 可能不被尊重？

有趣的是，SET DEADLOCK_PRIORITY MSDN 页面说 HIGH 映射到 5，而我的代码肯定使用 HIGH，所以我不确定 10 来自哪里。

令人讨厌的是，受害者是一个重要的业务流程，而幸存者都是 SSMS Intellisense 查询。

编辑

首先，这个问题是关于为什么不尊重 DEADLOCK_PRIORITY，而不是关于死锁是什么或如何防止或解决它们或导致下面示例中的死锁的原因。这些都是有趣的对话，但不是在这里。

其次，根据@SteveFord 找到的链接，还有一些可能相关的附加事实；此 SQL Server 上启用了锁定分区，并且 SQL Server 版本早于 2012 CU6（KB2776344 中的补丁发布时。

第三，对于那些对这里感兴趣的人来说，这里有一个经过清理的死锁图，显示了优先级较高的进程被选为受害者。我删除了 SQL 并更改了一些名称，其他一切都完好无损。

<deadlock>
  <victim-list>
    <victimProcess id="process5f390c8" />
  </victim-list>
  <process-list>
    <process id="process5f390c8" taskpriority="10" logused="3200" waitresource="KEY: 6:281474978938880 (655334c51469)" waittime="1806" ownerId="296690694" transactionname="ALTER PARTITION FUNCTION" lasttranstarted="2018-01-29T11:59:36.140" XDES="0x886312d28" lockMode="X" schedulerid="9" kpid="32684" status="suspended" spid="86" sbid="0" ecid="0" priority="5" trancount="1" lastbatchstarted="2018-01-29T11:58:38.310" lastbatchcompleted="2018-01-29T11:58:38.310" lastattention="1900-01-01T00:00:00.310" clientapp="CLIENTAPP" hostname="HOSTNAME" hostpid="10912" loginname="DOMAIN\USERNAME" isolationlevel="read committed (2)" xactid="296690694" currentdb="6" lockTimeout="4294967295" clientoption1="673187936" clientoption2="128056">
      <executionStack>
        <frame procname="adhoc" line="2" stmtstart="138" sqlhandle="0x01000600a1f28605207939860500000000000000000000000000000000000000000000000000000000000000">
...removed...</frame>
        <frame procname="mssqlsystemresource.sys.sp_executesql" line="1" stmtstart="-1" sqlhandle="0x0400ff7f427f99d9010000000000000000000000000000000000000000000000000000000000000000000000">
...removed...</frame>
        <frame procname="SUBSPNAME" line="75" stmtstart="5434" stmtend="5502" sqlhandle="0x0300060011b27f3d08e76c012ba8000001000000000000000000000000000000000000000000000000000000">
...removed...</frame>
        <frame procname="SPNAME" line="65" stmtstart="4234" stmtend="4516" sqlhandle="0x030006004990de353efaf70071a8000001000000000000000000000000000000000000000000000000000000">
...removed...</frame>
        <frame procname="adhoc" line="1" sqlhandle="0x01000600679e2e28907739860500000000000000000000000000000000000000000000000000000000000000">
...removed...</frame>
      </executionStack>
      <inputbuf>
...removed...</inputbuf>
    </process>
    <process id="process791872558" taskpriority="0" logused="0" waitresource="OBJECT: 6:139251651:11 " waittime="8299" ownerId="300839454" transactionname="MDView" lasttranstarted="2018-01-29T12:19:33.727" XDES="0x4cddd58a0" lockMode="Sch-S" schedulerid="9" kpid="20372" status="suspended" spid="75" sbid="0" ecid="0" priority="0" trancount="0" lastbatchstarted="2018-01-29T12:19:33.720" lastbatchcompleted="2018-01-29T12:19:33.713" lastattention="2018-01-29T12:19:18.360" clientapp="Microsoft SQL Server Management Studio" hostname="ANOTHERHOSTNAME" hostpid="62236" loginname="DOMAIN\ANOTHERUSERNAME" isolationlevel="read committed (2)" xactid="300839326" currentdb="6" lockTimeout="10000" clientoption1="671090784" clientoption2="128056">
      <executionStack>
        <frame procname="adhoc" line="1" stmtstart="56" sqlhandle="0x02000000c7bca00d097183e2d5dd8e6785f452180936fd930000000000000000000000000000000000000000">
...removed...</frame>
        <frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
...removed...</frame>
      </executionStack>
      <inputbuf>
...removed...</inputbuf>
    </process>
  </process-list>
  <resource-list>
    <keylock hobtid="281474978938880" dbid="6" objectname="DBNAME.sys.sysschobjs" indexname="clst" id="lock1ef508c700" mode="U" associatedObjectId="281474978938880">
      <owner-list>
        <owner id="process791872558" mode="S" />
      </owner-list>
      <waiter-list>
        <waiter id="process5f390c8" mode="X" requestType="convert" />
      </waiter-list>
    </keylock>
    <objectlock lockPartition="11" objid="139251651" subresource="FULL" dbid="6" objectname="TABLENAME" id="lock398e43e00" mode="Sch-M" associatedObjectId="139251651">
      <owner-list>
        <owner id="process5f390c8" mode="Sch-M" />
      </owner-list>
      <waiter-list>
        <waiter id="process791872558" mode="Sch-S" requestType="wait" />
      </waiter-list>
    </objectlock>
  </resource-list>
</deadlock>

【问题讨论】：

如果您提供死锁图会很有帮助
@SteveFord 问题是关于为什么 DEADLOCK_PRIORITY 可能不被遵守，而不是为什么会发生任何特定的死锁。我希望有人以前观察过这种行为，或者比我更了解 DEADLOCK_PRIORITY 的内部工作原理。我正在下班发帖，无论如何都无法轻松发布图表而无需进行大量消毒。
这篇文章中有一些可能原因的描述：sqlservercentral.com/Forums/Topic1662375-391-1.aspx。要考虑的另一件事是您是否面临超时而不是死锁受害者。 SSMS 默认运行时没有锁定超时，但这可以配置。
图表是什么样的？特别是，您的查询是否同时与多个其他查询发生死锁？这是推测，但基于死锁事件总是提到“死锁受害者”这一事实，算法可能更愿意找到一个受害者来解决死锁，即使如果唯一的选择是杀死多个进程，则受害者比其他参与者具有更高的优先级。（如果有点乏味的话，应该可以通过设置死锁情况来验证这一点。）
如果您还没有，那么值得设置一个永久事件通知来捕获表中的所有死锁事件（例如，参见here）。这使得事后调查死锁更加方便（并且还允许您找到模式并确定优先级）。

标签： sql-server sql-server-2012 deadlock

【解决方案1】：

看起来被杀死的命令是一个 ALTER PARTITION FUNCTION，有趣的是，这需要一个 SCH-M 锁，它与用于所有内容的 SCH-S 锁不兼容。我想这可能是一个原因。

见michaeljswart.com/2013/04/the-sch-m-lock-is-evil。

另请参阅 ALTER PARTITION 函数中的 SCH-M 死锁描述以及导致 SQL 2014 和 2016 中的统计信息更新的查询，但在 2012 年也可能如此：Deadlock Occurs when you acquire a SCH-M lock

查看您的图表，一个进程在 sysschobjs 上有一个共享（更新）锁，并且正在等待您的表上的 SCH-S 锁。您的进程在您的表上有一个 SCH-M 锁，并且正在等待 sysschobjs 上的 X 锁。 sysschobjs 是位于 sysobjects 后面的系统基表。请参阅此处的讨论Technet: SQL Query that causes deadlock often

希望对你有帮助

更新如果您想进一步研究，我发现了死锁监视器如何选择受害者的 MS 专利描述 here

【讨论】：