Prayer

大家在開(kāi)發(fā)、測(cè)試過(guò)程中，常見(jiàn)到程序報(bào)911這樣的錯(cuò)，查看一下幫助：

d:/>db2 ? sql0911n


SQL0911N因?yàn)樗梨i或超時(shí)，所以當(dāng)前事務(wù)已回滾。原因碼為
          "<原因碼>"。

解釋:

當(dāng)前工作單元涉及到未解決的對(duì)使用對(duì)象的爭(zhēng)用，因此不得不回滾。

原因碼如下：


 2 由于死鎖而導(dǎo)致事務(wù)已回滾。

 68 由于鎖定超時(shí)而導(dǎo)致事務(wù)已回滾。

 72 因?yàn)榇嬖谂c事務(wù)中所涉及的 DB2 Data Links Manager
有關(guān)的錯(cuò)誤，所以事務(wù)已回滾。

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

應(yīng)用程序已回滾至上一次 COMMIT。

用戶響應(yīng):

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

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

當(dāng)處理 SQL 語(yǔ)句的某些組合時(shí)，通常會(huì)發(fā)生死鎖或者預(yù)期會(huì)發(fā)生死鎖。建議
您設(shè)計(jì)應(yīng)用程序來(lái)盡可能避免死鎖。

 sqlcode :  -911

 sqlstate :  40001


d:/>

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

怎么區(qū)分呢？

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

超時(shí)解決辦法：
     1、優(yōu)化相關(guān)sql
     2、延長(zhǎng)超時(shí)設(shè)置

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


-- The End --