如何避免死鎖而多發的過程中SQL對同桌工作

Question

我們能否避免死鎖通過不同的工藝

例如創建不同的數據庫用戶一個用戶與API'ABC'進行通信，另一個用戶與API'PQR'以及其他用戶進行通信以處理API'ABC'和'PQR'帶來的系統數據？所有這些用戶將處理相同的表格。

Answer 1

就個人而言，您可以將一個時間戳列添加到表中，以便在多個用戶同時更新行時幫助維護數據庫的完整性。您可能還想知道有多少行和更新了哪些行，而無需重新查詢該表。

CREATE TABLE MyTest (myKey int PRIMARY KEY, myValue int, RV rowversion); 

然後，你就可以使用下面的示例Transact-SQL語句執行更新過程中的[表名稱]表樂觀併發控制。

DECLARE @t TABLE (myKey int); 
UPDATE MyTest 
SET myValue = 2 
    OUTPUT inserted.myKey INTO @t(myKey) 
WHERE myKey = 1 
    AND RV = [row-version-value]; 
IF (SELECT COUNT(*) FROM @t) = 0 
    BEGIN 
     RAISERROR ('error changing row with myKey = %d' 
      ,16 -- Severity. 
      ,1 -- State 
      ,1) -- myKey that was changed 
    END; 

Answer 2

死鎖發生，因爲相同的資源（表，索引，行等），SQL服務器並不關心誰是會話的所有者，也可以是有多個相同的用戶不同的作戰會議會話或多個用戶。因此，僅僅爲了避免死鎖而創建多個用戶是無濟於事的。

東西，可以幫助.....

1. 以相同的順序訪問對象。
2. 避免交易中的用戶交互。
3. 保持交易短和在一個批次。
4. 使用較低的隔離級別（謹慎）。
5. 使用基於行版本控制的隔離級別。
6. 將READ_COMMITTED_SNAPSHOT數據庫選項設置爲ON以啓用讀取已提交的事務以使用行版本控制。
7. 如果可能的話，使用快照隔離（注意它會將你的tempdb嚇跑）。

看一看這個Minimizing Deadlocks

Answer 3

我想這將防止死鎖，因爲你將有不同的用戶訪問不同的過程但難道不真正解決死鎖問題。在兩個實體訪問同一條數據/數據被阻止，然後沒有人能完成交易的情況下，死鎖更多。它更像是一個捕捉22的情況，他們都在等待另一個完成，但他們都不能。爲不同的進程創建不同的用戶可以防止死鎖，但它並不實際。

一個正常的做法/最好的做法僅僅是使交易被鎖定在當實體訪問它們一定的順序系統使用的鎖編程。這將防止任何事務陷入死鎖情況，並且如果一個事務正在使用數據，另一個試圖訪問同一個事件的另一個事務將被迫等待對方完成，然後才能繼續。

Answer 4

它可能不適合所有情況，但我們嘗試處理存儲過程中的處理邏輯並使用'sp_getapplock'來防止同時使用過程事務。

Answer 5

不，首先找到死鎖受害者看看這個article。在大多數情況下，它缺乏索引或不好的索引會導致死鎖...

如果你可以發佈我們的死鎖細節，我們可以建議一個最好的解決方案。

根據您所要求的更好地設置priority以避免死鎖。