瞭解特定類型的死鎖

我想了解特定類型的死鎖是如何發生的。瞭解特定類型的死鎖

我有一個非常簡單的死鎖圖與兩個資源和兩個進程。一個是運行SELECT另一個UPDATE聲明。我知道有些情況會導致死鎖，但我不明白在這種情況下會發生什麼。

被害人查詢：

SELECT id_particle, id_event, dt_created, dt_rcvd, tlx_no, from_routename, re, deleted 
FROM msg_list 
WHERE to_routename = @P0 
AND ((dt_answ IS NULL AND b_complete = 0 AND id_event=6) OR (id_event = 10 AND deleted = 0) 
OR (from_id_post = 9705 AND deleted = 0)) 
ORDER BY dt_created ASC

冠軍獎金查詢：

UPDATE msg_list 
SET 
    ID_EVENT=7, 
    STATUS='Answered', 
    DT_ANSW={ts '2017-02-12 05:34:14' 
WHERE ID_PARTICLE = 46211816

完整的僵局圖：

<deadlock-list> 
<deadlock victim="process30aa42d468"> 
    <process-list> 
    <process id="process30aa42d468" taskpriority="0" logused="0" waitresource="PAGE: 6:1:155679 " waittime="921" ownerId="427175775" transactionname="SELECT" lasttranstarted="2017-02-12T05:34:48.293" XDES="0x3126fbba40" lockMode="S" schedulerid="4" kpid="10648" status="suspended" spid="184" sbid="0" ecid="0" priority="0" trancount="0" lastbatchstarted="2017-02-12T05:34:48.293" lastbatchcompleted="2017-02-12T05:34:48.280" lastattention="1900-01-01T00:00:00.280" clientapp="jTDS" hostname="LNS" hostpid="123" loginname="MsgStore" isolationlevel="read committed (2)" xactid="427175775" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> 
    <executionStack> 
    <frame procname="tempdb.dbo.#jtds000003_____________________________________________________________________________________________________________0042FD9D" line="1" stmtstart="92" stmtend="668" sqlhandle="0x030002005819e1b4efce580018a7000001000000000000000000000000000000000000000000000000000000"> 
SELECT id_particle, id_event, dt_created, dt_rcvd, tlx_no, from_routename, re, deleted FROM msg_list WHERE to_routename = @P0 AND ((dt_answ IS NULL AND b_complete = 0 AND id_event=6) OR (id_event = 10 AND deleted = 0) OR (from_id_post = 9705 AND deleted = 0)) ORDER BY dt_created AS  </frame> 
    </executionStack> 
    <inputbuf> 
Proc [Database Id = 2 Object Id = -1260316328] </inputbuf> 
    </process> 
    <process id="process319282aca8" taskpriority="0" logused="21256" waitresource="PAGE: 6:1:396658 " waittime="869" ownerId="427175573" transactionname="implicit_transaction" lasttranstarted="2017-02-12T05:34:48.210" XDES="0x30c2dbc408" lockMode="IX" schedulerid="4" kpid="11980" status="suspended" spid="99" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2017-02-12T05:34:48.430" lastbatchcompleted="2017-02-12T05:34:48.427" lastattention="2017-02-12T03:34:28.130" clientapp="NotesMover" hostname="LNS" hostpid="8828" loginname="Notesmover" isolationlevel="read committed (2)" xactid="427175573" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058"> 
    <executionStack> 
    <frame procname="adhoc" line="1" stmtstart="364" stmtend="812" sqlhandle="0x020000006d523b316d15563a50b97ce8d56da3cf6d8fc4450000000000000000000000000000000000000000"> 
unknown  </frame> 
    <frame procname="adhoc" line="1" stmtend="554" sqlhandle="0x02000000d8b78713c51b1588947edf24f2d7b69031f4f1d60000000000000000000000000000000000000000"> 
unknown  </frame> 
    <frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"> 
unknown  </frame> 
    </executionStack> 
    <inputbuf> 
UPDATE msg_list SET ID_EVENT=7, STATUS='Answered', DT_ANSW={ts '2017-02-12 05:34:14'WHERE ID_PARTICLE = 46211816  
    </inputbuf> 
    </process> 
    </process-list> 
    <resource-list> 
    <pagelock fileid="1" pageid="155679" dbid="6" subresource="FULL" objectname="MsgStore.dbo.msg_list" id="lock31683f2400" mode="IX" associatedObjectId="72057594523811840"> 
    <owner-list> 
    <owner id="process319282aca8" mode="IX"/> 
    </owner-list> 
    <waiter-list> 
    <waiter id="process30aa42d468" mode="S" requestType="wait"/> 
    </waiter-list> 
    </pagelock> 
    <pagelock fileid="1" pageid="396658" dbid="6" subresource="FULL" objectname="MsgStore.dbo.msg_list" id="lock2f80c2e300" mode="S" associatedObjectId="72057594523811840"> 
    <owner-list> 
    <owner id="process30aa42d468" mode="S"/> 
    </owner-list> 
    <waiter-list> 
    <waiter id="process319282aca8" mode="IX" requestType="wait"/> 
    </waiter-list> 
    </pagelock> 
    </resource-list> 
</deadlock> 
</deadlock-list>

和它們的圖形表示：

這裏是正在運行這兩個查詢時生成的查詢計劃：

的受害者：

優勝者：

由受害者使用的ncci_rcvd_list指數是一個非聚集覆蓋索引與單個鍵柱和幾個包含的列。其中一列包括專欄由獲勝者更新。關鍵列未更新。

mgs_list表有大約500,000條記錄。 SELECT查詢返回的結果集通常只有幾十行左右（儘管偶爾它可能會更大，可能是幾千）。

有人可以解釋這種情況如何導致僵局嗎？

這是從生產系統捕獲的，這種情況發生頻率很高。我已經通過將事務隔離級別更改爲讀取已提交的快照來解決此問題，這不再是問題，但我想了解發生的事情，然後查看是否存在不同的解決方案。

來源

2017-02-14 IamNaN

您可以將執行計劃粘貼爲xml並共享 – TheGameiswar

頁面155679在IX模式下由process319282aca8（UPDATE）擁有，並且在S模式下由process30aa42d468（SELECT）提供。 S在S模式下由SELECT擁有，並且在IX模式下由UPDATE使用。

問題是兩個查詢都缺少索引。 UPDATE使用索引但沒有覆蓋，因此需要將RID查找到聚集索引。 SELECT是一個掃描（如頁面級鎖S給出的...）。這可以保證併發下的死鎖。

這是濫用表格作爲隊列的另一個例子。閱讀Using tables as Queues。將你的狀態與你的事件分開。僅入隊和出隊事件。

PS。 '受害者'將始終是回滾較少的事務，並且在讀取或寫入時，這總是讀取。另外，我懷疑你發佈的SELECT執行計劃是實際死鎖的計劃。

來源

2017-02-14 10:37:53

順便說一句，您是否有該表上的任何UPDATE觸發器？ –

是的，該表上確實有一個簡單的更新觸發器。它更新另一個數據庫中統計表中的記錄。否則，閱讀鏈接的文檔...除非它包含在該文檔中，你能解釋爲什麼你認爲該選擇是掃描並且計劃是'假'？畢竟，select語句有一個覆蓋索引，這是我每次手動運行該查詢時得到的計劃。 – IamNaN

@RemusRusanu：您是如何識別的，在執行堆棧框架中存在表格 – TheGameiswar

瞭解特定類型的死鎖

回答

相關問題