SQL Server：在锁定通信缓冲区资源上死锁

#1 楼

常见的完整消息是：


事务（进程ID 53）在锁定时死锁|通信
缓冲与另一个进程的资源，并已被选择为死锁受害者。重新运行事务。


这种锁类型在SQL Server已并行执行的死锁查询中很常见，有时称为“查询内并行死锁”。我已经看到一些陈述，这也指出系统资源不足，我认为这可能会涉及到很小的程度。

我注意到的确定它是否为并行死锁的一般准则是，当您拉出XML死锁图（可以在2008年及更高版本的system_health会话中完成）时，您会注意到不同的进程ID在执行堆栈中显示相同的代码。

还要查看死锁图的资源列表，并注意等待事件的类型。它们通常会显示“ e_xxxxxx”，或者类似这样的内容：

<waiter-list>
 <waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>

要尝试解决该问题，在线和书籍中提供了多种选择。我通常首先查看查询/过程的执行计划，然后重点关注显示并行执行的区域。然后从那里开始尝试首先调整查询，然后在最后的手段开始使用查询提示。

您将看到解决这些死锁的最常见查询提示是实现MAXDOP 1。但是，在此之前，您可能需要检查服务器级别MAXDOP和“成本阈值”设置为什么。成本阈值通常默认情况下设置为5，我想将其设置为35或40作为开始，如果所讨论的查询的代码段成本较低，则可能根本不需要并行运行。我不是很喜欢使用MAXDOP查询提示，但这并不意味着它们没有自己的位置和目的。只是我的意见。