DB2故障處理的思路及一般問題的解決辦法
我認為解決問題的關鍵在于分清問題的種類，并清楚每種問題的解決辦法。另外很多的數據庫的問題都是由于錯誤的操作，錯誤的配置引起的，所以本文在解釋怎么樣處理問題時也會給出一些好的建議，來避免產生問題。本文重點介紹實用的方法。
對問題的分類有很多種方法，在本文中我我采用了兩種分類方案。
第一種方案是是否有錯誤碼。即發生錯誤時是否同時返回了錯誤碼，錯誤碼既包括執行命令的返回碼，也包擴應用程序的返回碼。
有返回碼的錯誤解決方案是，在db2 CLP中運行db2 ? SQLXXXX，然后根據對該問題的解釋采取相應的解決方案。對沒有錯誤碼的問題，如數據庫hang，CPU使用率過高等問題，解決問題的經驗將非常重要，在本文中會有詳細的說明。
根據錯誤碼解決問題舉例（在下文中，再出現需要用這種方法解決問題時將不再重復）：
如在連接數據庫時發生錯誤
db2 connect to sample |
錯誤碼分為返回碼（SQL0332N）和原因碼（Reason Code "1"），針對不同的原因碼有不同的解決方案
運行db2 ? sql0332
從輸出種可以看到對于reason code 1的解釋是
…… |
所以可以通過設置代碼頁來解決這個問題
db2set db2codepage=1386 |
就可以成功連接了。
第二種分類方案是按照問題的范圍和性質進行分類。分類如下：
1．數據庫實例問題
2．數據庫問題
3．數據庫性能問題
4．應用開發與數據庫有關的問題
下面對每一類問題進行詳細說明。
一、數據庫實例的問題
數據庫實例問題可以分為兩種情況
1．實例無法啟動，運行db2start后，直接返回錯誤碼，如SQL1042C。
如果根據錯誤碼信息無法解決，可以嘗試如下方案：
重新更新該實例，以root身份登錄，
cd /usr/opt/db2_08_01/instance/ |
Tip：常見的產生實例無法啟動的原因
數據庫安裝了新的補丁后沒有運行db2iupdt
數據庫文件的權限被改成了777，數據庫文件的權限是有要求的，所以不能將所有的文件都改成777的權限
數據庫實例文件被刪除或損壞
主機名與db2nodes.cfg里記錄的不一致
2．運行db2start時，hang在那里，既不報錯，也無法啟動實例
這種情況一般是由于實例沒有正常的停止造成的，一般運行下列命令可以解決：
su - |
(將所有的與該實例有關的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 /DDEL |
按照提示輸入表名，表空間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 > sql.out |
這個快照記錄了動態語句的快照信息，可以根據
Total execution time (sec.ms) = 0.000000 |
這些信息來找到最耗時的語句。
2．怎么樣優化sql語句
DB2提供了很好的工具來做sql語句優化。首先要對找到的sql語句進行分析，看是否是該語句引起了性能問題。我們可以使用db2expln來查看sql語句的訪問計劃和執行成本。
首先將找到的sql語句寫到一個文本文件中sql.in，以“；”結尾，然后運行
db2expln –d -f -z “;” –g –o sql.exp |
查看sql.exp可以看到這個sql語句的執行成本。
如果確認該語句有問題，可以使用db2advis來通過建索引的方法來優化該語句
db2advis –d -i sql.in |
如果通過創建索引無法優化該語句，一般只能從業務角度優化。
3．如果發生鎖的問題怎么樣處理
發生鎖的問題，一般有兩種情況，一是鎖等待，二是死鎖。首先檢查數據庫配置參數locktimeout，該參數一定不能設為－1，因為會引起某些應用無限期的等待。
可以通過快照來確定數據庫發生的問題是哪一種。
db2 get snapshot for db on |
查看輸出中的下列內容：
Deadlocks detected = 0 |
如果發生了死鎖，可以通過創建死鎖監視器來分析產生死鎖的原因，命令如下：
mkdir /tmp/dlmon |
【編輯推薦】
