2012-04-04 84 views
3

故事我怎麼能強迫3960

的快照隔離故障我有使用快照隔離通過合併執行幾個插入一個存儲過程。此SPROC以非常高的負載調用,並且通常並行調用,因此偶爾會引發錯誤3960-這表明快照由於更改衝突而回滾。由於高併發性,這是預期的。

問題

我已經實現了一個「重試」的隊列稍後再執行此工作,但我有困難再現錯誤來驗證我的支票是準確的。

問題

我怎樣才能重現快照失敗(3960,特別是)來驗證我的重試邏輯是工作?

已經嘗試過

  • RAISEERROR不起作用,因爲它不容許我提出存在的錯誤,只有用戶定義的人
  • 我已經試過重新插入相同的記錄,但這不會引發同樣的錯誤,因爲它不是兩個不同的交易「賽車」另一
+1

如果您已經獨立於實際的錯誤捕獲測試了各個部分,那麼您可以使用代碼。如果你的新代碼失敗並錯過了錯誤,那麼現在它失敗的時候就不會更糟。 – 2012-04-10 17:26:40

回答

0

爲什麼不只是這樣做:

RAISERROR(3960, {sev}, {state}) 

將{sev}和{state}替換爲在生產中發生錯誤時看到的實際值?

(不,馬丁指出,這是行不通的。)


如果不是,那麼我會建議試圖同時運行測試查詢多次。我自己做了這個來模擬其他併發錯誤。只要測試查詢不是太快(至少幾秒),應該可行。

+1

'RAISERROR'不能用於引發系統錯誤編號。 – 2012-04-10 19:18:14

+1

呵呵,對吧。猜猜我以前從未嘗試過...無論如何,其他方法應該工作(如果測試查詢不是太快)。 *我以前做過*。 – RBarryYoung 2012-04-10 19:21:54

+0

感謝您的回覆!我沒有花時間嘗試重新創造競爭條件,沒有任何運氣。最終,團隊決定代碼支持足夠的日誌記錄,因此它被批准實時部署。 – Jordan 2012-04-11 20:01:14

1

打開兩個連接,開始在兩個快照事務,在連接1次更新的記錄,在連接2更新相同的記錄(在背景,因爲它會阻止),然後在連接1提交

或治療用戶錯誤爲3960 ...