對DB2故障處理及最佳實(shí)踐的淺析
所以本文在解釋如何DB2故障處理問題時(shí)也會(huì)相應(yīng)給出一些建議，來避免產(chǎn)生問題。當(dāng)你在使用數(shù)據(jù)庫時(shí)，可能會(huì)遇到各種不同的問題。我個(gè)人認(rèn)為解決問題最為關(guān)鍵的是在于分清問題的種類，并清楚每種問題的解決辦法。
另外很多的數(shù)據(jù)庫的問題都是由于錯(cuò)誤的操作，錯(cuò)誤的配置引起的，所以本文在解釋如何DB2故障處理問題時(shí)也會(huì)給出一些好的建議，來避免產(chǎn)生問題。本文重點(diǎn)介紹實(shí)用的方法。
對問題的分類有很多種方法，在本文中我我采用了兩種分類方案。
***種方案是是否有錯(cuò)誤碼。即發(fā)生錯(cuò)誤時(shí)是否同時(shí)返回了錯(cuò)誤碼，錯(cuò)誤碼既包括執(zhí)行命令的返回碼，也包擴(kuò)應(yīng)用程序的返回碼。
有返回碼的錯(cuò)誤解決方案是，在db2 CLP中運(yùn)行 db2 ? SQLXXXX，然后根據(jù)對該問題的解釋采取相應(yīng)的解決方案。對沒有錯(cuò)誤碼的問題，如數(shù)據(jù)庫hang，CPU使用率過高等問題，解決問題的經(jīng)驗(yàn)將非常重要，在本文中會(huì)有詳細(xì)的說明。
根據(jù)錯(cuò)誤碼解決問題舉例(在下文中，再出現(xiàn)需要用這種方法解決問題時(shí)將不再重復(fù))：
如在連接數(shù)據(jù)庫時(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")，針對不同的原因碼有不同的解決方案
運(yùn)行db2 ? sql0332
從輸出種可以看到對于 reason code 1的解釋是
……
1 source and target code page combination is not supported by the database manager.
……
所以可以通過設(shè)置代碼頁來解決這個(gè)問題
- db2set db2codepage=1386
- db2 terminate
- db2 connect to sample
就可以成功連接了。
第二種分類方案是按照問題的范圍和性質(zhì)進(jìn)行分類。分類如下：
1.數(shù)據(jù)庫實(shí)例問題
2.數(shù)據(jù)庫問題
3.數(shù)據(jù)庫性能問題
4.應(yīng)用開發(fā)與數(shù)據(jù)庫有關(guān)的問題
淺談DB2故障處理及***實(shí)踐，下面對每一類問題進(jìn)行詳細(xì)說明。
一、數(shù)據(jù)庫實(shí)例的問題
數(shù)據(jù)庫實(shí)例問題可以分為兩種情況
1實(shí)例無法啟動(dòng)，運(yùn)行db2start后，直接返回錯(cuò)誤碼，如SQL1042C。
如果根據(jù)錯(cuò)誤碼信息無法解決，可以嘗試如下方案：
重新更新該實(shí)例，以root身份登錄，
- cd /usr/opt/db2_08_01/instance/
- ./db2iupdt
Tip：常見的產(chǎn)生實(shí)例無法啟動(dòng)的原因
數(shù)據(jù)庫安裝了新的補(bǔ)丁后沒有運(yùn)行db2iupdt
數(shù)據(jù)庫文件的權(quán)限被改成了777，數(shù)據(jù)庫文件的權(quán)限是有要求的，所以不能將所有的文件都改成777的權(quán)限
數(shù)據(jù)庫實(shí)例文件被刪除或損壞
主機(jī)名與db2nodes.cfg里記錄的不一致
2.運(yùn)行db2start時(shí)，hang在那里，既不報(bào)錯(cuò)，也無法啟動(dòng)實(shí)例
這種情況一般是由于實(shí)例沒有正常的停止造成的，一般運(yùn)行下列命令可以解決：
- su -
- db2_kill
- ipclean
- su – root
(將所有的與該實(shí)例有關(guān)的db2進(jìn)程殺死 kill -9 )
然后重新啟動(dòng)實(shí)例。
3.數(shù)據(jù)庫實(shí)例崩潰問題
遇到實(shí)例崩潰的問題，首先查看db2diag.log，根據(jù)里面的信息來分析數(shù)據(jù)庫宕機(jī)的原因。再看db2dump目錄中是否有trap文件?？梢愿鶕?jù)這些信息來分析原因，一般這類問題都需要IBM工程師協(xié)助解決。
宕機(jī)的原因可以分為兩類，一類是數(shù)據(jù)庫的BUG，即數(shù)據(jù)庫的缺陷引起的，一般如果遇到了數(shù)據(jù)庫的缺陷，都有臨時(shí)的解決方案，或者通過安裝***的補(bǔ)丁來解決，對某些問題IBM也提供臨時(shí)的修訂來解決(需要付費(fèi))。另一類是操作系統(tǒng)，誤操作等非產(chǎn)品問題導(dǎo)致的，對非產(chǎn)品問題導(dǎo)致的宕機(jī)盡量要避免。
Tip：常見的數(shù)據(jù)庫宕機(jī)原因
系統(tǒng)的交換空間(paging space)用盡
數(shù)據(jù)庫的某個(gè)進(jìn)程被kill
二、數(shù)據(jù)庫問題
1.數(shù)據(jù)連接問題
無法連接數(shù)據(jù)庫，常見的錯(cuò)誤有代碼頁錯(cuò)誤，通訊協(xié)議錯(cuò)誤，數(shù)據(jù)庫狀態(tài)錯(cuò)誤等。
對代碼頁類錯(cuò)誤，可以通過設(shè)置db2codepage，db2country來解決，這兩個(gè)變量需要用db2set 設(shè)置成與數(shù)據(jù)庫一致的值。
當(dāng)發(fā)生通訊類錯(cuò)誤時(shí)，首先要要檢查環(huán)境變量DB2COMM=TCPIP是否已經(jīng)設(shè)置，然后要檢查dbm cfg的SVCENAME，該變量可以直接設(shè)置成端口號(hào)，或者設(shè)置成服務(wù)名，該服務(wù)名要在services文件中設(shè)置成對應(yīng)的端口號(hào)。要檢查該端口號(hào)是否已經(jīng)被其他服務(wù)占用。在啟動(dòng)數(shù)據(jù)庫后，可以運(yùn)行netstat –an |grep ，來查看該端口處于的狀態(tài)。
TCP 0.0.0.0:50000 0.0.0.0:0 LISTENING
還有一種情況，當(dāng)連接數(shù)據(jù)庫時(shí)，數(shù)據(jù)庫處于backup pending 狀態(tài)，無法連接。這是只要對數(shù)據(jù)庫做一個(gè)備份就可以了。
Tip：通常導(dǎo)致數(shù)據(jù)庫處于備份贊掛的原因
當(dāng)一個(gè)數(shù)據(jù)庫從循環(huán)日志改成歸檔日志時(shí)，數(shù)據(jù)庫要求進(jìn)行一次脫機(jī)備份，在重新啟動(dòng)數(shù)據(jù)庫后，數(shù)據(jù)庫就處于備份贊掛的狀態(tài)
對于一個(gè)使用線形日志的數(shù)據(jù)庫，當(dāng)做load時(shí)，表空間會(huì)處于備份贊掛的狀態(tài)，為了避免這種情況，load命令需要使用copy yes，或者nonrecoverable參數(shù)。
2.數(shù)據(jù)庫損壞
數(shù)據(jù)庫最嚴(yán)重的問題莫過于數(shù)據(jù)庫損壞，那么當(dāng)數(shù)據(jù)庫損壞時(shí)，***的辦法是從備份恢復(fù)數(shù)據(jù)庫。
如果無法從備份恢復(fù)，可以根據(jù)損壞的原因嘗試相應(yīng)的解決方案。
由于存儲(chǔ)問題導(dǎo)致部分?jǐn)?shù)據(jù)文件損壞，但是數(shù)據(jù)庫還可以連接，這種情況可以采用導(dǎo)出數(shù)據(jù)庫的表結(jié)果和數(shù)據(jù)的方法來恢復(fù)數(shù)據(jù)庫。當(dāng)然對損壞的表，導(dǎo)出是無法完成的，這是可以使用db2dart的導(dǎo)出數(shù)據(jù)功能來導(dǎo)出這些損壞的表的數(shù)據(jù)。
如果數(shù)據(jù)庫損壞到已經(jīng)無法連接的程度，那么除了從備份恢復(fù)，唯一的辦法是使用db2dart來導(dǎo)出所有的數(shù)據(jù)了。
以上的相關(guān)內(nèi)容就是對淺談DB2故障處理及***實(shí)踐的介紹，望你能有所收獲。
【編輯推薦】
