gpt4 book ai didi

c# - SQL Server 2008 R2 查询通知死锁 (SqlDependency)

转载 作者:太空宇宙 更新时间:2023-11-03 11:21:10 24 4
gpt4 key购买 nike

我在 SQL Server 2008 R2 上遇到了死锁问题。在 SQL Profiler 中查看死锁图时,问题似乎源于查询通知:

  <resource-list>
<keylock hobtid="72057654759522304" dbid="6" objectname="MyDB.sys.query_notification_814081939" indexname="cidx" id="lock15ab2aa80" mode="RangeX-X" associatedObjectId="72057654759522304">
<owner-list>
<owner id="process5c5708" mode="RangeX-X"/>
</owner-list>
<waiter-list>
<waiter id="process4e9ae08" mode="RangeS-U" requestType="wait"/>
</waiter-list>
</keylock>
<keylock hobtid="72057654759522304" dbid="6" objectname="MyDB.sys.query_notification_814081939" indexname="cidx" id="lock15e56a300" mode="RangeS-U" associatedObjectId="72057654759522304">
<owner-list>
<owner id="process4e9ae08" mode="RangeS-U"/>
</owner-list>
<waiter-list>
<waiter id="process5c5708" mode="RangeS-U" requestType="wait"/>
</waiter-list>
</keylock>
</resource-list>

这些查询通知是使用 SQLDependency 实现的。更新由 SQLDependency 监视的表时似乎发生了死锁。

死锁图语法我不是很懂..KeyLock模式是RangeS-U only while using the serializable transaction isolation level. , 正确的 ?

我也读过这个 question ...我应该激活 READ_COMMITED_SNAPSHOT 吗?

谢谢...

最佳答案

不能确定,但​​这里有一些想法......

导致通知的语句可能在通知传递之前未完成。因此,当从 Service Broker 收到通知并对通知采取任何操作时,它可能仍然具有事件锁。

也许您的通知收件人正在尝试清理队列或在生成第一个通知的事务完成之前从队列中获取第二个通知。

生成通知的 DML 是否在多步事务中运行?是在多步事务中运行的接收通知的代码。 (即您是否使用了 begin tran 或等价物?)。

跟踪死锁图中提到的进程并了解哪些代码持有 RangeX-X 锁以及哪些代码持有 RangeS-U 可能很有用。

您可能想发布一些生成通知的代码和接收通知的代码的最小示例。

这里还有一个 Microsoft 知识库文章,关于通知和多个订阅的已知有点类似的死锁问题。

MS KB975090 Might be relevant, but not exactly the same.

关于c# - SQL Server 2008 R2 查询通知死锁 (SqlDependency),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10951645/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com