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

對問題的分類有很多種方法，在本文中我我采用了兩種分類方案。

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

有返回碼的錯誤解決方案是，在db2 CLP中運行 db2 ? SQLXXXX，然后根據(jù)對該問題的解釋采取相應的解決方案。對沒有錯誤碼的問題，如數(shù)據(jù)庫hang，CPU使用率過高等問題，解決問題的經(jīng)驗將非常重要，在本文中會有詳細的說明。

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

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

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

錯誤碼分為返回碼(SQL0332N)和原因碼(Reason Code '1')，針對不同的原因碼有不同的解決方案

運行db2 ? sql0332

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

……

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

……

所以可以通過設置代碼頁來解決這個問題

db2set db2codepage=1386

db2 terminate

db2 connect to sample

就可以成功連接了。

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

1.數(shù)據(jù)庫實例問題

2.數(shù)據(jù)庫問題

3.數(shù)據(jù)庫性能問題

4.應用開發(fā)與數(shù)據(jù)庫有關的問題

下面對每一類問題進行詳細說明。

一、數(shù)據(jù)庫實例的問題

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

1實例無法啟動，運行db2start后，直接返回錯誤碼，如SQL1042C。

如果根據(jù)錯誤碼信息無法解決，可以嘗試如下方案：

重新更新該實例，以root身份登錄，

cd /usr/opt/db2_08_01/instance/

./db2iupdt

Tip：常見的產(chǎn)生實例無法啟動的原因

數(shù)據(jù)庫安裝了新的補丁后沒有運行db2iupdt

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

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

主機名與db2nodes.cfg里記錄的不一致

2.運行db2start時，hang在那里，既不報錯，也無法啟動實例

這種情況一般是由于實例沒有正常的停止造成的，一般運行下列命令可以解決：

su -

db2_kill

ipclean

su – root

(將所有的與該實例有關的db2進程殺死 kill -9 )

然后重新啟動實例。

3.數(shù)據(jù)庫實例崩潰問題

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

宕機的原因可以分為兩類，一類是數(shù)據(jù)庫的BUG，即數(shù)據(jù)庫的缺陷引起的，一般如果遇到了數(shù)據(jù)庫的缺陷，都有臨時的解決方案，或者通過安裝最新的補丁來解決，對某些問題IBM也提供臨時的修訂來解決(需要付費)。另一類是操作系統(tǒng)，誤操作等非產(chǎn)品問題導致的，對非產(chǎn)品問題導致的宕機盡量要避免。

Tip：常見的數(shù)據(jù)庫宕機原因

系統(tǒng)的交換空間(paging space)用盡

數(shù)據(jù)庫的某個進程被kill

二、數(shù)據(jù)庫問題

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

無法連接數(shù)據(jù)庫，常見的錯誤有代碼頁錯誤，通訊協(xié)議錯誤，數(shù)據(jù)庫狀態(tài)錯誤等。

對代碼頁類錯誤，可以通過設置db2codepage，db2country來解決，這兩個變量需要用db2set 設置成與數(shù)據(jù)庫一致的值。

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

TCP 0.0.0.0:50000 0.0.0.0:0 LISTENING

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

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

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

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

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

數(shù)據(jù)庫最嚴重的問題莫過于數(shù)據(jù)庫損壞，那么當數(shù)據(jù)庫損壞時，最好的辦法是從備份恢復數(shù)據(jù)庫。

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

由于存儲問題導致部分數(shù)據(jù)文件損壞，但是數(shù)據(jù)庫還可以連接，這種情況可以采用導出數(shù)據(jù)庫的表結果和數(shù)據(jù)的方法來恢復數(shù)據(jù)庫。當然對損壞的表，導出是無法完成的，這是可以使用db2dart的導出數(shù)據(jù)功能來導出這些損壞的表的數(shù)據(jù)。

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

Tip：如何使用db2dart來導出數(shù)據(jù)

運行命令 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)，

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

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

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

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

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

啟用數(shù)據(jù)庫的鏡像日志功能

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

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

三、數(shù)據(jù)庫性能問題

數(shù)據(jù)庫的性能問題一般不屬于故障，但是當性能問題變得很嚴重時，就變成了故障。

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

確認性能問題首先要從系統(tǒng)的資源消耗來分析，一般可以借助操作系統(tǒng)的工具，如aix的topas命令。數(shù)據(jù)庫的性能問題一般的表現(xiàn)是應用變慢，甚至沒有響應。

Tip：如何快速定位問題

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

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

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

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

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

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

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

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

在系統(tǒng)最繁忙的時候，運行

db2 get snapshot for all applications > app.out

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

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

db2 get snapshot for dynamic sql on > sql.out

這個快照記錄了動態(tài)語句的快照信息，可以根據(jù)

Total execution time (sec.ms) = 0.000000

Total user cpu time (sec.ms) = 0.000000

Total system cpu time (sec.ms) = 0.000000

這些信息來找到最耗時的語句。

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

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

首先將找到的sql語句寫到一個文本文件中sql.in，以“;”結尾，然后運行

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

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

如果確認該語句有問題，可以使用db2advis來通過建索引的方法來優(yōu)化該語句

db2advis –d -i sql.in

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

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

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

可以通過快照來確定數(shù)據(jù)庫發(fā)生的問題是哪一種。

db2 get snapshot for db on

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

Deadlocks detected = 0

Lock Timeouts = 0

如果發(fā)生了死鎖，可以通過創(chuàng)建死鎖監(jiān)視器來分析產(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文件就可以找到造成死鎖的信息，結合應用就可以找到造成死鎖的原因了。

四、應用開發(fā)與數(shù)據(jù)庫有關的問題

1.與64位實例數(shù)據(jù)庫問題

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

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

可以通過創(chuàng)建一個32位實例的客戶端，然后通過客戶端來使用64位實例數(shù)據(jù)庫的方法來將64位的問題完全忽略。

如果使用java 存儲過程或自定義函數(shù)，64位實例數(shù)據(jù)庫需要安裝64位的JDK。

2.從DB2 V7移植程序到V8有關問題

sqlc的應用程序中，數(shù)據(jù)類型long在V8中需要改成sqlint32，否則編譯無法通過。如果確定long類型的數(shù)據(jù)長度與平臺無關，也可以在編譯時，指定LONGERROR NO選項。

在編譯sqlc程序時可能會遇到sql20230的錯誤，原因是在V8中不允許在call中使用主機變量，將執(zhí)行語句改成動態(tài)sql后，可以解決該問題。

在執(zhí)行存儲過程時，遇到sql0433的錯誤，原因同上，將call 存儲過程的語句改成動態(tài)調(diào)用即可。

3.Java程序問題

編寫良好的程序是避免產(chǎn)生問題的關鍵。對JAVA程序有如下建議，一定要用數(shù)據(jù)庫的連接池;在執(zhí)行大量的sql語句時使用prepared statement。

結束語

本文描述常見的數(shù)據(jù)庫故障，并給出了簡單有效的解決方案。對某些技術問題，如命令的使用沒有詳細介紹，當需要時可以查閱DB2相關的文檔。