重試查詢

Question

最近，在我們村，我們注意到在某些集的存儲過程死鎖的增加，這些都是很簡單：

• 插入表在表
• 更新記錄基礎在主鍵

這個表有太多觸發器和這些ocasionally與另一個存儲過程，即以小時爲單位運行衝突，並導致死鎖。

我周圍的Googling跌跌撞撞這篇文章後：https://www.simple-talk.com/sql/database-administration/handling-deadlocks-in-sql-server/

它建議以下模式來處理死鎖程序：

DECLARE @retries INT ; 
SET @retries = 4 ; 

WHILE (@retries > 0) 
    BEGIN 
     BEGIN TRY 
      BEGIN TRANSACTION ; 

     -- place sql code here 
      SET @retries = 0 ; 

      COMMIT TRANSACTION ; 
     END TRY 
     BEGIN CATCH 
     -- Error is a deadlock 
      IF (ERROR_NUMBER() = 1205) 
       SET @retries = @retries - 1 ; 

     -- Error is not a deadlock 
      ELSE 
       BEGIN 
        DECLARE @ErrorMessage NVARCHAR(4000) ; 
        DECLARE @ErrorSeverity INT ; 
        DECLARE @ErrorState INT ; 

        SELECT @ErrorMessage = ERROR_MESSAGE() , 
          @ErrorSeverity = ERROR_SEVERITY() , 
          @ErrorState = ERROR_STATE() ; 

        -- Re-Raise the Error that caused the problem 
        RAISERROR (@ErrorMessage, -- Message text. 
         @ErrorSeverity, -- Severity. 
         @ErrorState -- State. 
         ) ; 
        SET @retries = 0 ; 
       END 

      IF XACT_STATE() <> 0 
       ROLLBACK TRANSACTION ; 
     END CATCH ; 
    END ; 
GO 

它幾乎使代碼的第二，第三和第四的成功機會和只有然後拋出一個錯誤。

我的問題是，這是否是一種健康的模式來處理前沿情況下的死鎖，並且是一種實際的解決方案而不是解決問題的方法？

Answer 1

免責聲明：本答案只有一個意見:)

該解決方案看起來像它會工作給我。但是，我不相信這是一個實際的解決方案，而是一種解決方法。這將是最好的，而不是試圖找出是什麼導致你的僵局開始並解決這個問題。

如果你不能解決死鎖的原因，那麼這樣的解決方法不會太糟糕，但確實只是解決實際問題。