在MS SQL上更新查詢時減少PAGE級別上的死鎖

在默認的「READ COMMITED」事務下，在平坦的普通表上，有一個愚蠢的簡單SQL UPDATE查詢導致了一些有趣的死鎖。在MS SQL上更新查詢時減少PAGE級別上的死鎖

更新表SET列= @ P1 WHERE PK = @ P2; 雖然PK varchar（11），它有一個聚集索引。桌子上沒有觸發器或表格關係..等等。

我做了一些檢查，發現死鎖發生在「PAGE」級別，而不是ROW /記錄級別。然後，我發現對於每個更新查詢，它需要100個（和更多）PAGE鎖。（這對我沒有意義，因爲我一次更新一行）

有沒有什麼辦法可以防止死鎖的發生？或者，如何在不使用光標的情況下減少單個行更新所需的鎖定數量？

感謝您的建議。

我曾嘗試重建索引幾次，填充因子高低。我試圖讓流程更新不同的位置/切片。但沒有什麼改善或最壞的。

我試過了SQL Server Profiler。我捕獲了一些「鎖：死鎖鏈」和「鎖：死鎖」，但沒有「死鎖圖」被捕獲。雙方都在讀取提交的自動提交模式下執行簡單的更新查詢。

Lock:Deadlock Chain 17887475 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     Lock:Deadlock Chain 17887476 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 209 1:438102                                                               265006271  0 0X56AF060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock Chain 17887477 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     Lock:Deadlock Chain 17887478 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 54 1:426206                                                               265006240  0 0XDE80060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock Chain 17887479 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 209 1:426206                                                               265006271  0 0XDE80060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock Chain 17887480 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     Lock:Deadlock Chain 17887481 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 54 1:426066                                                               265006240  0 0X5280060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock Chain 17887482 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 209 1:426066                                                               265006271  0 0X5280060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock Chain 17887483 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     Lock:Deadlock Chain 17887484 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 209 1:425614                                                               265006271  0 0X8E7E060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock Chain 17887485 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     Lock:Deadlock Chain 17887486 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 209 1:426687                                                               265006271  0 0XBF82060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock Chain 17887487 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     
Lock:Deadlock Chain 17887488 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 209 1:425392                                                               265006271  0 0XB07D060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock Chain 17887489 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     
Lock:Deadlock Chain 17887491 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     
Lock:Deadlock Chain 17887493 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     
Lock:Deadlock Chain 17887494 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 209 1:435792                                                               265006271  0 0X50A6060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock Chain 17887495 1  0X01 4 myserver  2008-11-28 10:16:46.210 Parallel query worker thread was involved in a deadlock                 0   971497 102 - Resource type Exchange     
Lock:Deadlock Chain 17887496 1  0X01 4 myserver  2008-11-28 10:16:46.210 Deadlock Chain SPID = 209 1:438206                                                               265006271  0 0XBEAF060001000000000000001B0006  27    0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971497 101 - Resource type Lock     
Lock:Deadlock 17887497  myuser 0XCD85FBB269700B4AA2F4E8579D118999 209 myserver myuser 2008-11-28 10:16:45.930 1:426206 265006271 myapps 0 0XDE80060001000000000000001B0006 123 27 281 2008-11-28 10:16:46.210 myclient 0 - LOCK 4 - U   0 72057594040352768 1 - TRANSACTION 0 6 - PAGE mydatabase 971498

來源

2008-11-26 Dennis C

我終於必須通過在存儲過程中使用cusror來做一個解決方法。

但是，PAGE鎖的發生和解決方法仍然很有趣。

在谷歌的一些更多的搜索後，還有一些其他的人也有同樣的問題，他們（從MSDN論壇）建議關閉在SQL Server 2005中的並行，但我從來沒有得到一個機會去嘗試。

來源

2009-01-22 15:41:32

您有2個選項，以減少鎖升級：

1）添加WITH（ROWLOCK）提示要求SQL服務器採取更細粒度鎖（您的里程可能會有所不同：

WITH（ROWLOCK）
UPDATE SET表列 = @ P1 WHERE PK = @ P2;
雖然PK VARCHAR（11），具有聚簇索引上它沒有跳跳虎或表relation..etc 在桌子上。

2）以隨機順序更新行，這減少了行鎖升級爲頁鎖的可能性。

此外，確保該表上的索引是最新的可以減少鎖定。如果你要做大量的插入，可以留下填充因子（90是好的）。

來源

2008-11-26 15:17:57

在正常，簡單的情況下，這種類型的begavior並不常見。我對你的問題是：這次交易的'另一面'是什麼？什麼是正在運行並導致此死鎖的其他更新語句？我認爲，這將是診斷這個問題的關鍵。老實說，我的錢是在這另一個，迄今爲止身份不明的查詢是罪魁禍首。我現在在拉斯維加斯...

來源

2008-11-26 16:30:48

這是最奇怪的部分，另一方做完全相同的查詢，完整的另一個主鍵。 – 2008-11-26 16:38:15

而且我甚至會斷開/重新連接，以確保沒有任何隱藏的鎖/事務。 – 2008-11-26 16:39:36

你有沒有運行配置文件跟蹤？

火了SQL事件探查器，並創建一個標準的跟蹤與這些事件說：

鎖：死鎖圖形
鎖：鎖：死鎖的鏈
鎖：鎖：升級

應該提供詳細的死鎖的確切性質。

來源

2008-11-27 03:43:21

在更新語句之前，同一個事務內部是否發生了來自同一個表和相同記錄的select語句？在這些選擇中使用（上鎖鎖定提示）。

來源

2008-11-27 15:15:22 Arvo

沒有（重新連接後）或Pk的另一個簡單的SELECT查詢。我試圖添加「with（updlock）」之前，它擁有「行」更新鎖定，但它不能減少更新查詢中的任何「頁面」鎖定。 – 2008-11-27 15:33:31

桌子上有沒有更新觸發器？如果是這樣，觸發器的動作可能會導致你的死鎖。

來源

2008-12-29 17:00:27

在MS SQL上更新查詢時減少PAGE級別上的死鎖

回答

相關問題