當(dāng)你在使用數(shù)據(jù)庫(kù)時(shí)，可能會(huì)遇到各種不同的問(wèn)題。我認(rèn)為解決問(wèn)題的關(guān)鍵在于分清問(wèn)題的種類，并清楚每種問(wèn)題的解決辦法。另外很多的數(shù)據(jù)庫(kù)的問(wèn)題都是由于錯(cuò)誤的操作，錯(cuò)誤的配置引起的，所以本文在解釋如何處理問(wèn)題時(shí)也會(huì)給出一些好的建議，來(lái)避免產(chǎn)生問(wèn)題。本文重點(diǎn)介紹實(shí)用的方法。

　　對(duì)問(wèn)題的分類有很多種方法，在本文中我我采用了兩種分類方案。

　　第一種方案是是否有錯(cuò)誤碼。即發(fā)生錯(cuò)誤時(shí)是否同時(shí)返回了錯(cuò)誤碼，錯(cuò)誤碼既包括執(zhí)行命令的返回碼，也包擴(kuò)應(yīng)用程序的返回碼。

　　有返回碼的錯(cuò)誤解決方案是，在db2 CLP中運(yùn)行 db2 ? SQLXXXX，然后根據(jù)對(duì)該問(wèn)題的解釋采取相應(yīng)的解決方案。對(duì)沒(méi)有錯(cuò)誤碼的問(wèn)題，如數(shù)據(jù)庫(kù)hang，CPU使用率過(guò)高等問(wèn)題，解決問(wèn)題的經(jīng)驗(yàn)將非常重要，在本文中會(huì)有詳細(xì)的說(shuō)明。

　　根據(jù)錯(cuò)誤碼解決問(wèn)題舉例(在下文中，再出現(xiàn)需要用這種方法解決問(wèn)題時(shí)將不再重復(fù))：

　　如在連接數(shù)據(jù)庫(kù)時(shí)發(fā)生錯(cuò)誤

　　db2 connect to sample

　　SQL0332N There is no available conversion for the source code page \"1386\" to

　　the target code page \"819\". Reason Code \"1\". SQLSTATE=57017

　　錯(cuò)誤碼分為返回碼(SQL0332N)和原因碼(Reason Code \"1\")，針對(duì)不同的原因碼有不同的解決方案

　　運(yùn)行db2 ? sql0332

　　從輸出種可以看到對(duì)于 reason code 1的解釋是

　　……

　　1 source and target code page combination is not supported by the database manager.

　　……

　　所以可以通過(guò)設(shè)置代碼頁(yè)來(lái)解決這個(gè)問(wèn)題

　　db2set db2codepage=1386

　　db2 terminate

　　db2 connect to sample

　　就可以成功連接了。

　　第二種分類方案是按照問(wèn)題的范圍和性質(zhì)進(jìn)行分類。分類如下：

　　1.數(shù)據(jù)庫(kù)實(shí)例問(wèn)題

　　4.應(yīng)用開(kāi)發(fā)與數(shù)據(jù)庫(kù)有關(guān)的問(wèn)題

　　下面對(duì)每一類問(wèn)題進(jìn)行詳細(xì)說(shuō)明。

　　數(shù)據(jù)庫(kù)實(shí)例問(wèn)題可以分為兩種情況

　　如果根據(jù)錯(cuò)誤碼信息無(wú)法解決，可以嘗試如下方案： 軟件開(kāi)發(fā)網(wǎng)

　　重新更新該實(shí)例，以root身份登錄，

　　./db2iupdt

　　Tip：常見(jiàn)的產(chǎn)生實(shí)例無(wú)法啟動(dòng)的原因

　　數(shù)據(jù)庫(kù)安裝了新的補(bǔ)丁后沒(méi)有運(yùn)行db2iupdt

　　數(shù)據(jù)庫(kù)文件的權(quán)限被改成了777，數(shù)據(jù)庫(kù)文件的權(quán)限是有要求的，所以不能將所有的文件都改成777的權(quán)限

　　數(shù)據(jù)庫(kù)實(shí)例文件被刪除或損壞

　　主機(jī)名與db2nodes.cfg里記錄的不一致

　　2.運(yùn)行db2start時(shí)，hang在那里，既不報(bào)錯(cuò)，也無(wú)法啟動(dòng)實(shí)例

　　這種情況一般是由于實(shí)例沒(méi)有正常的停止造成的，一般運(yùn)行下列命令可以解決：

　　su - http://www.

　　db2_kill

　　ipclean

　　su – root

　　(將所有的與該實(shí)例有關(guān)的db2進(jìn)程殺死 kill -9 )

　　然后重新啟動(dòng)實(shí)例。

　　3.數(shù)據(jù)庫(kù)實(shí)例崩潰問(wèn)題

　　遇到實(shí)例崩潰的問(wèn)題，首先查看db2diag.log，根據(jù)里面的信息來(lái)分析數(shù)據(jù)庫(kù)宕機(jī)的原因。再看db2dump目錄中是否有trap文件?？梢愿鶕?jù)這些信息來(lái)分析原因，一般這類問(wèn)題都需要IBM工程師協(xié)助解決。 http://www.

　　系統(tǒng)的交換空間(paging space)用盡 http://www.

　　數(shù)據(jù)庫(kù)的某個(gè)進(jìn)程被kill

　　二、數(shù)據(jù)庫(kù)問(wèn)題 http://www.

　　1.數(shù)據(jù)連接問(wèn)題

　　無(wú)法連接數(shù)據(jù)庫(kù)，常見(jiàn)的錯(cuò)誤有代碼頁(yè)錯(cuò)誤，通訊協(xié)議錯(cuò)誤，數(shù)據(jù)庫(kù)狀態(tài)錯(cuò)誤等。

　　對(duì)代碼頁(yè)類錯(cuò)誤，可以通過(guò)設(shè)置db2codepage，db2country來(lái)解決，這兩個(gè)變量需要用db2set 設(shè)置成與數(shù)據(jù)庫(kù)一致的值。

　　當(dāng)發(fā)生通訊類錯(cuò)誤時(shí)，首先要要檢查環(huán)境變量DB2COMM=TCPIP是否已經(jīng)設(shè)置，然后要檢查dbm cfg的SVCENAME，該變量可以直接設(shè)置成端口號(hào)，或者設(shè)置成服務(wù)名，該服務(wù)名要在services文件中設(shè)置成對(duì)應(yīng)的端口號(hào)。要檢查該端口號(hào)是否已經(jīng)被其他服務(wù)占用。在啟動(dòng)數(shù)據(jù)庫(kù)后，可以運(yùn)行netstat –an |grep ，來(lái)查看該端口處于的狀態(tài)。

　　TCP 0.0.0.0:50000 0.0.0.0:0 LISTENING 軟件開(kāi)發(fā)網(wǎng)

　　還有一種情況，當(dāng)連接數(shù)據(jù)庫(kù)時(shí)，數(shù)據(jù)庫(kù)處于backup pending 狀態(tài)，無(wú)法連接。這是只要對(duì)數(shù)據(jù)庫(kù)做一個(gè)備份就可以了。

　　Tip：通常導(dǎo)致數(shù)據(jù)庫(kù)處于備份贊掛的原因

　　當(dāng)一個(gè)數(shù)據(jù)庫(kù)從循環(huán)日志改成歸檔日志時(shí)，數(shù)據(jù)庫(kù)要求進(jìn)行一次脫機(jī)備份，在重新啟動(dòng)數(shù)據(jù)庫(kù)后，數(shù)據(jù)庫(kù)就處于備份贊掛的狀態(tài)

　　對(duì)于一個(gè)使用線形日志的數(shù)據(jù)庫(kù)，當(dāng)做load時(shí)，表空間會(huì)處于備份贊掛的狀態(tài)，為了避免這種情況，load命令需要使用copy yes，或者nonrecoverable參數(shù)。

　　2.數(shù)據(jù)庫(kù)損壞

　　數(shù)據(jù)庫(kù)最嚴(yán)重的問(wèn)題莫過(guò)于數(shù)據(jù)庫(kù)損壞，那么當(dāng)數(shù)據(jù)庫(kù)損壞時(shí)，最好的辦法是從備份恢復(fù)數(shù)據(jù)庫(kù)。

　　如果無(wú)法從備份恢復(fù)，可以根據(jù)損壞的原因嘗試相應(yīng)的解決方案。

　　由于存儲(chǔ)問(wèn)題導(dǎo)致部分?jǐn)?shù)據(jù)文件損壞，但是數(shù)據(jù)庫(kù)還可以連接，這種情況可以采用導(dǎo)出數(shù)據(jù)庫(kù)的表結(jié)果和數(shù)據(jù)的方法來(lái)恢復(fù)數(shù)據(jù)庫(kù)。當(dāng)然對(duì)損壞的表，導(dǎo)出是無(wú)法完成的，這是可以使用db2dart的導(dǎo)出數(shù)據(jù)功能來(lái)導(dǎo)出這些損壞的表的數(shù)據(jù)。

　　如果數(shù)據(jù)庫(kù)損壞到已經(jīng)無(wú)法連接的程度，那么除了從備份恢復(fù)，唯一的辦法是使用db2dart來(lái)導(dǎo)出所有的數(shù)據(jù)了。

　　Tip：如何使用db2dart來(lái)導(dǎo)出數(shù)據(jù)

　　運(yùn)行命令 db2dart /DDEL

　　# Table object data formatting start.

　　# Please enter

　　# Table ID or name， tablespace ID， first page， num of pages:

　　# (suffic page number with 'p' for pool relative)， 軟件開(kāi)發(fā)網(wǎng)

　　按照提示輸入表名，表空間id，起始頁(yè)數(shù)，需要導(dǎo)出的頁(yè)數(shù)

　　3.數(shù)據(jù)庫(kù)的活動(dòng)日志被刪除

　　這個(gè)問(wèn)題經(jīng)常會(huì)遇到。也屬于數(shù)據(jù)庫(kù)損壞的一種情況。并且數(shù)據(jù)庫(kù)無(wú)法連接。

　　首先考慮是否有可以恢復(fù)的備份，如果有，可以從備份恢復(fù)，然后前滾到日志的末尾，可以完全恢復(fù)該數(shù)據(jù)庫(kù)。如果沒(méi)有可用的備份來(lái)恢復(fù)，可以通過(guò)IBM的技術(shù)支持中心來(lái)協(xié)助解決。如果想自己解決那只有使用db2dart工具了。

　　Tip：如何避免數(shù)據(jù)庫(kù)的活動(dòng)日志被刪除

　　啟用數(shù)據(jù)庫(kù)的鏡像日志功能 http://www.

　　啟用數(shù)據(jù)庫(kù)的日志出口程序，這樣可以避免手工來(lái)刪除活動(dòng)日志目錄中的日志

　　當(dāng)一定要手工刪除活動(dòng)日志目錄中的歸檔日志時(shí)，使用命令 PRUNE LOGFILE PRIOR TO log-file-name，可以避免失誤將活動(dòng)日志刪除

　　三、數(shù)據(jù)庫(kù)性能問(wèn)題

　　數(shù)據(jù)庫(kù)的性能問(wèn)題一般不屬于故障，但是當(dāng)性能問(wèn)題變得很嚴(yán)重時(shí)，就變成了故障。

　　解決數(shù)據(jù)庫(kù)的性能問(wèn)題，可以從以下方面入手，檢查數(shù)據(jù)庫(kù)的配置，如緩沖池，排序堆等是否合理;檢查數(shù)據(jù)庫(kù)是否收集過(guò)統(tǒng)計(jì)信息，準(zhǔn)確的統(tǒng)計(jì)信息對(duì)語(yǔ)句優(yōu)化起著重要的左右;對(duì)sql語(yǔ)句進(jìn)行優(yōu)化;查看是否有系統(tǒng)資源瓶頸。

　　如果系統(tǒng)的CPU利用很高，IO很少，那么數(shù)據(jù)庫(kù)的排序較多

　　如果系統(tǒng)的IO繁忙，CPU很多是wait，那么說(shuō)明數(shù)據(jù)庫(kù)有過(guò)多的IO

　　如果系統(tǒng)CPU，IO都很空閑，那么說(shuō)明可以是有鎖的問(wèn)題

　　如果系統(tǒng)IO，CPU都非常忙，說(shuō)明有執(zhí)行代價(jià)非常高的sql在執(zhí)行

　　數(shù)據(jù)庫(kù)一般有三類的性能問(wèn)題，一是CPU占用過(guò)多，二是IO過(guò)于繁忙，三是有鎖等待。

　　1.快速找到執(zhí)行成本較高的sql

　　首先要打開(kāi)監(jiān)視器的開(kāi)關(guān)

　　db2 update monitor switches using bufferpool on lock on sort on statement on table on uow on

　　在系統(tǒng)最繁忙的時(shí)候，運(yùn)行

　　db2 get snapshot for all applications > app.out

　　然后在該文件中查找處于Executing狀態(tài)的應(yīng)用，找到執(zhí)行的對(duì)應(yīng)的sql語(yǔ)句。

　　如果用這種方法找不到，可以收集sql的快照

　　db2 get snapshot for dynamic sql on > sql.out

　　這個(gè)快照記錄了動(dòng)態(tài)語(yǔ)句的快照信息，可以根據(jù)

　　Total execution time (sec.ms) = 0.000000

　　Total user cpu time (sec.ms) = 0.000000 軟件開(kāi)發(fā)網(wǎng)

　　Total system cpu time (sec.ms) = 0.000000

　　這些信息來(lái)找到最耗時(shí)的語(yǔ)句。

　　2.如何優(yōu)化sql語(yǔ)句

　　DB2提供了很好的工具來(lái)做sql語(yǔ)句優(yōu)化。首先要對(duì)找到的sql語(yǔ)句進(jìn)行分析，看是否是該語(yǔ)句引起了性能問(wèn)題。我們可以使用db2expln來(lái)查看sql語(yǔ)句的訪問(wèn)計(jì)劃和執(zhí)行成本。 http://www.

　　首先將找到的sql語(yǔ)句寫(xiě)到一個(gè)文本文件中sql.in，以“;”結(jié)尾，然后運(yùn)行

　　db2expln –d -f -z “;” –g –o sql.exp

　　查看 sql.exp可以看到這個(gè)sql語(yǔ)句的執(zhí)行成本。

　　如果確認(rèn)該語(yǔ)句有問(wèn)題，可以使用db2advis來(lái)通過(guò)建索引的方法來(lái)優(yōu)化該語(yǔ)句

　　db2advis –d -i sql.in

　　如果通過(guò)創(chuàng)建索引無(wú)法優(yōu)化該語(yǔ)句，一般只能從業(yè)務(wù)角度優(yōu)化。

　　3.如果發(fā)生鎖的問(wèn)題如何處理

　　發(fā)生鎖的問(wèn)題，一般有兩種情況，一是鎖等待，二是死鎖。首先檢查數(shù)據(jù)庫(kù)配置參數(shù)locktimeout，該參數(shù)一定不能設(shè)為-1，因?yàn)闀?huì)引起某些應(yīng)用無(wú)限期的等待。

　　可以通過(guò)快照來(lái)確定數(shù)據(jù)庫(kù)發(fā)生的問(wèn)題是哪一種。

　　db2 get snapshot for db on

　　查看輸出中的下列內(nèi)容：

　　Deadlocks detected = 0

　　Lock Timeouts = 0

　　如果發(fā)生了死鎖，可以通過(guò)創(chuàng)建死鎖監(jiān)視器來(lái)分析產(chǎn)生死鎖的原因，命令如下：

　　mkdir /tmp/dlmon

　　db2 connect to

　　db2 create event monitor dlmon for deadlocks with detail write to file ‘/tmp/dlmon’ replace

　　db2 set event monitor dlmon state 1

　　…..等有死鎖發(fā)生后

　　db2 set event monitor dlmon state 0

　　db2evmon –d /tmp/dlmon >/tmp/dlmon.out

　　分析/tmp/dlmon.out文件就可以找到造成死鎖的信息，結(jié)合應(yīng)用就可以找到造成死鎖的原因了。

　　四、應(yīng)用開(kāi)發(fā)與數(shù)據(jù)庫(kù)有關(guān)的問(wèn)題

　　1.與64位實(shí)例數(shù)據(jù)庫(kù)問(wèn)題 軟件開(kāi)發(fā)網(wǎng)

　　目前隨著硬件的升級(jí)，64位實(shí)例數(shù)據(jù)庫(kù)開(kāi)始廣泛使用。

　　有些人擔(dān)心數(shù)據(jù)庫(kù)使用64位以后，對(duì)程序的運(yùn)行很大，因此不愿意使用64位的數(shù)據(jù)庫(kù)，實(shí)際上64位數(shù)據(jù)庫(kù)對(duì)客戶的應(yīng)用影響非常小，所以建議如果資源充足，盡量使用64位實(shí)例的數(shù)據(jù)庫(kù)。