淺談DB2數據庫的故障處理及最佳實踐

就可以成功連接了。

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

1．數據庫實例問題

2．數據庫問題

3．數據庫性能問題

4．應用開發與數據庫有關的問題

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

一、數據庫實例的問題

數據庫實例問題可以分為兩種情況

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

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

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

Tip：常見的產生實例無法啟動的原因

數據庫安裝了新的補丁後沒有運行db2iupdt

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

數據庫實例文件被刪除或損壞

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

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

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

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

然後重新啟動實例。

3．數據庫實例崩潰問題

遇到實例崩潰的問題，首先查看db2diag.log，根據裡面的信息來分析數據庫宕機的原因。再看db2dump目錄中是否有trap文件。可以根據這些信息來分析原因，一般這類問題都需要IBM工程師協助解決。

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

Tip：常見的數據庫宕機原因

系統的交換空間（paging space）用盡

數據庫的某個進程被kill

二、數據庫問題

1．數據連接問題

無法連接數據庫，常見的錯誤有代碼頁錯誤，通訊協議錯誤，數據庫狀態錯誤等。

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

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

TCP　　0.0.0.0:50000　　　　　0.0.0.0:0　　　　　　　LISTENING

還有一種情況，當連接數據庫時，數據庫處於backup pending 狀態，無法連接。這是只要對數據庫做一個備份就可以了。

Tip：通常導致數據庫處於備份贊掛的原因

當一個數據庫從循環日志改成歸檔日志時，數據庫要求進行一次脫機備份，在重新啟動數據庫後，數據庫就處於備份贊掛的狀態

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

2．數據庫損壞

數據庫最嚴重的問題莫過於數據庫損壞，那麼當數據庫損壞時，最好的辦法是從備份恢復數據庫。

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

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

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

Tip：如何使用db2dart來導出數據

運行命令

db2dart <dbname> /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，起始頁數，需要導出的頁數

3．數據庫的活動日志被刪除

這個問題經常會遇到。也屬於數據庫損壞的一種情況。並且數據庫無法連接。

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

Tip：如何避免數據庫的活動日志被刪除

啟用數據庫的鏡像日志功能

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

當一定要手工刪除活動日志目錄中的歸檔日志時，使用命令

PRUNE LOGFILE PRIOR TO log-file-name，]

可以避免失誤將活動日志刪除

三、數據庫性能問題

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

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

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

Tip：如何快速定位問題

如果系統的CPU利用很高，IO很少，那麼數據庫的排序較多

如果系統的IO繁忙，CPU很多是wait，那麼說明數據庫有過多的IO

如果系統CPU，IO都很空閒，那麼說明可以是有鎖的問題

如果系統IO，CPU都非常忙，說明有執行代價非常高的sql在執行

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

1．快速找到執行成本較高的sql

首先要打開監視器的開關

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

在系統最繁忙的時候，運行

db2 get snapshot for all applications > app.out

然後在該文件中查找處於Executing狀態的應用，找到執行的對應的sql語句。

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

db2 get snapshot for dynamic sql on <dbname> > sql.out

這個快照記錄了動態語句的快照信息，可以根據

Total execution time (sec.ms)　　　= 0.000000
Total user cpu time (sec.ms)　　　 = 0.000000
Total system cpu time (sec.ms)　　 = 0.000000

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

2．如何優化sql語句

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

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

db2expln –d <dbname> -f <sql.in> -z “;” –g –o sql.exp