2012-06-08 146 views
2

我正在運行SQL Server 2008 R2上的死鎖問題。當在SQL事件探查器死鎖圖形看,問題似乎從查詢通知制止:查詢通知(SqlDependency)SQL Server 2008 R2 DeadLock

<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嗎?

THX ...

+0

你有沒有想過這個?我也看到了使用SqlDependency/Query Notification導致死鎖的情況。 –

+0

我有相同的死鎖問題,但沒有公開交易。你弄明白了嗎? – dferidarov

+0

除了我在下面的答案中列出的Microsoft給出的建議,我沒有真正的解決方案。 – LB40

回答

2

不能針下來是肯定的,但這裏有一些想法...

引起通知的通知交付前可能無法完成該語句。因此,當從服務代理收到通知並且對通知採取任何操作時,它可能仍然具有活動鎖。

也許您的通知收件人正在嘗試清理隊列或在生成第一個通知的事務完成之前從隊列中取出第二個通知。

生成通知的DML是否在多步事務中運行?接收通知的代碼是否在多步事務中運行。 (即你是否使用begin tran或同等的?)。

追查死鎖圖中提到的進程並瞭解哪些代碼持有RangeX-X鎖並保存RangeS-U會很有用。

您可能想要發佈一些生成通知的代碼和接收它的代碼的最小示例。

此處還有一個Microsoft知識庫,其中介紹了一個已知的有點類似死鎖問題的通知和多個訂閱。

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

0

背後的主要原因是,交易是太長,涉及太多的對象。 正如我在我的問題中所說的,sqldependency被激發的表包含對數據庫中每個對象的引用。在同一個事務中更新一堆對象意味着查詢通知系統在這個大表上鎖定。因此,你很快就陷入了僵局。

2解決方案(由MS建議): - 減少交易的長度和複雜性。 - 執行在大事務之外觸發通知系統的請求。

希望它有幫助...