Prayer

大家在開發(fā)、測試過程中，常見到程序報911這樣的錯，查看一下幫助：

d:/>db2 ? sql0911n


SQL0911N因為死鎖或超時，所以當前事務已回滾。原因碼為
          "<原因碼>"。

解釋:

當前工作單元涉及到未解決的對使用對象的爭用，因此不得不回滾。

原因碼如下：


 2 由于死鎖而導致事務已回滾。

 68 由于鎖定超時而導致事務已回滾。

 72 因為存在與事務中所涉及的 DB2 Data Links Manager
有關的錯誤，所以事務已回滾。

注釋: 必須再次輸入與工作單元相關的更改。

應用程序已回滾至上一次 COMMIT。

用戶響應:

為了幫助避免死鎖或鎖定超時，對長時間運行的應用程序或有可能遇到死鎖
的應用程序頻繁發(fā)出 COMMIT 操作（如果有可能的話）。

聯(lián)合系統(tǒng)用戶：死鎖可能發(fā)生在聯(lián)合服務器或數(shù)據(jù)源上。沒有檢測跨越數(shù)據(jù)
源并潛在地跨越聯(lián)合系統(tǒng)的死鎖的機制。有可能標識使請求失敗的數(shù)據(jù)源（
參閱 Problem Determination Guide 以確定哪一個數(shù)據(jù)源使 SQL
語句的處理失敗）。

當處理 SQL 語句的某些組合時，通常會發(fā)生死鎖或者預期會發(fā)生死鎖。建議
您設計應用程序來盡可能避免死鎖。

 sqlcode :  -911

 sqlstate :  40001


d:/>

很明顯是兩種原因可能造成這樣的錯誤。
1、死鎖
2、鎖等待超時

怎么區(qū)分呢？

思路：
     根據(jù)原因碼，如果是2就是死鎖引起的；如果是68就是超時引起的。
     如果沒有獲得原因碼，那么從系統(tǒng)自帶的死鎖監(jiān)視器里確認是否發(fā)生過死鎖，如果沒有發(fā)生，則就是超時引起的。

超時解決辦法：
     1、優(yōu)化相關sql
     2、延長超時設置

死鎖分析方法：
     用實例用戶連接到db2實例，切換到死鎖監(jiān)視器路徑下，運行db2evmon -path xxx >lock_rpt.txt來生成報告。


-- The End --