Lock communication buffer resources
这个指示的系统是否内存不足,缓冲区计数超出限制？
详细错误：
Transaction (Process ID 59) was deadlocked on lock communication
buffer resources with another process and has been chosen as the
deadlock victim. Rerun the transaction
解决方法
Transaction (Process ID 53) was deadlocked on lock | communication
buffer resources with another process and has been chosen as the
deadlock victim. Rerun the transaction.
这种锁类型常见于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和Cost Threshold的设置.默认情况下,成本阈值通常设置为5,我喜欢将其提高到35或40开始,如果有问题的查询对于该段代码的成本较低,则可能根本不需要并行运行.我不是那么喜欢使用MAXDOP查询提示,但这并不意味着他们没有自己的位置和目的.只是我的观点.
