SQL0911N錯誤處理記錄

問題描述：
在系統運行時候，在SAP系統中經常報sql -911錯誤，reason code ”68”導致程序運行失敗。
問題分析：
察看sql 911詳細錯誤信息如下：
D:\>db2 ? sql0911n
SQL0911N因為死鎖或超時，所以當前事務已回滾。原因碼為
          "<原因碼>"。

解釋:

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

原因碼如下：
 2 由於死鎖而導致事務已回滾。

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

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

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

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

用戶響應:

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

聯合系統用戶：死鎖可能發生在聯合服務器或數據源上。沒有檢測跨越數據
源並潛在地跨越聯合系統的死鎖的機制。有可能標識使請求失敗的數據源（
參閱 Problem Determination Guide 以確定哪一個數據源使 SQL
語句的處理失敗）。

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

 sqlcode :  -911

 sqlstate :  40001

因為事務返回碼為68,所以導致事務運行失敗的原因是 由於鎖定超時而導致事務已回滾。
對數據庫進行快照監控，查看鎖快照想過信息：
Deadlocks detected                         = 0
Lock escalations                           = 0
Exclusive lock escalations                 = 0
Agents currently waiting on locks          = 0
Lock Timeouts                              = 9
從上面的快照信息可以看出，數據庫並沒有發生死鎖，而是發生了9次鎖定超時，而且數據庫沒有鎖定升級的情況出現，因為可以判斷造成數據庫鎖定超時的原因應該是由於事務本身執行時間較長導致的，而和數據庫鎖定參數locklist，maxlocks沒有關系。
目前的數據庫鎖定超時參數LOCKTIMEOUT 為3600秒（1個小時），決定加大此參數值，將其增加到7200秒（2個小時）以延長事務的鎖定等待時間。
修改方法：
Db2 update db cfg for epp using locktimeout 7200 immediate

修改后，需要重新啟動數據庫，以使參數生效
Db2stop force
Db2start