[[237041]]

斷電、硬件故障……這些都可能導致數(shù)據(jù)庫壞頁，進而引發(fā)數(shù)據(jù)庫崩潰。本文記錄了一次生產(chǎn)環(huán)境中 Db2 數(shù)據(jù)庫壞頁的故障處理，詳細分享了如何恢復絕大部分數(shù)據(jù)，并恢復數(shù)據(jù)庫的正常運行。

前言

數(shù)據(jù)庫最嚴重的故障莫過于數(shù)據(jù)庫損壞。數(shù)據(jù)庫壞頁是數(shù)據(jù)庫損壞的一種，如果數(shù)據(jù)庫中有數(shù)據(jù)頁出現(xiàn)損壞，在沒有訪問到壞頁時，數(shù)據(jù)庫可以正常提供服務，當使用到壞頁所在的表，有可能導致數(shù)據(jù)庫的崩潰。

導致數(shù)據(jù)庫出現(xiàn)壞頁的可能性有很多，比如突然的掉電、主機down機，或者存儲、磁盤的故障等等。

當數(shù)據(jù)庫出現(xiàn)壞頁時，首先使用操作系統(tǒng)命令判斷是否出現(xiàn)硬件故障，修復硬件故障后，可以嘗試使用"db2 restart db dbname"命令讓數(shù)據(jù)庫執(zhí)行崩潰恢復，這種方法有可能恢復數(shù)據(jù)庫的正常。如果不適用與上述方法，那么***的辦法就是從備份恢復數(shù)據(jù)庫。

如果無法從備份恢復，那么在數(shù)據(jù)庫可以連接的情況下，可以采用db2look導出表結構和export導出數(shù)據(jù)的方法來重建數(shù)據(jù)庫。當然對于損壞的表，只能使用db2dart工具離線導出這些表的數(shù)據(jù)，處于壞頁上的數(shù)據(jù)庫極有可能丟失了。

如果數(shù)據(jù)庫無法連接了，只能使用db2dart離線導出整個數(shù)據(jù)庫的數(shù)據(jù)。導出數(shù)據(jù)之后，剩下的就是重建庫并且導入數(shù)據(jù)了。

本文記錄了一次生產(chǎn)環(huán)境中數(shù)據(jù)庫頁頭的損壞的數(shù)據(jù)庫壞頁故障，經(jīng)過一波三折的修復過程，最終恢復了絕大部分數(shù)據(jù)，恢復了數(shù)據(jù)庫的正常運行。

環(huán)境介紹

操作系統(tǒng)版本 AIX 6100-07-04-1216

數(shù)據(jù)庫版本 DB2 v9.7.0.7

該數(shù)據(jù)庫比較大，大概2.2T，出現(xiàn)壞頁的表數(shù)據(jù)量也比較大，大概30G。

一、問題發(fā)現(xiàn)

業(yè)務人員查詢XXX數(shù)據(jù)庫的某個報表查詢，出現(xiàn)如下報錯：

二、初步分析

查看該報錯的解釋：

db2 "? sql1655c" 

查看數(shù)據(jù)庫的nfy日志：

more db2npsh.nfy 

2017-08-07-14.14.44.308129 Instance:db2npsh Node:000  
PID:12517626(db2agent (NPSH) 0) TID:25497 Appid:*LOCAL.db2npsh.170807055005  
buffer pool services sqlbReadPage Probe:1199 Database:NPSH  
ADM6006E DB2 encountered an error while reading page "114482656" from table   
space "3" for object "1859" (located at offset "114482688" of container "/dev/rlvts_npsh_d8").  
 
 
2017-08-07-14.14.55.313501+480 E1900111A837 LEVEL: Critical  
PID : 12517626 TID : 11548 PROC : db2sysc 0  
INSTANCE: db2npsh NODE : 000  
EDUID : 11548 EDUNAME: db2pfchr (NPSH) 0  
FUNCTION: DB2 UDB, buffer pool services, sqlbLogReadAttemptFailure, probe:10  
MESSAGE : ADM14001C An unexpected and critical error has occurred: "BadPage".   
The instance may have been shutdown as a result. "Automatic" FODC   
(First Occurrence Data Capture) has been invoked and diagnostic   
information has been recorded in directory   
"/db2/dump/npsh/FODC_BadPage_2017-08-07-10.09.10.302693_0000/".   
Please look in this directory for detailed evidence about what   
happened and contact IBM support if necessary to diagnose the   
problem. 

同時，也發(fā)現(xiàn)dump目錄下生成FODC_BadPage的文件。

三、進一步分析

嘗試定位出現(xiàn)壞頁的表：

根據(jù)db2npsh.nfy 日志中的信息table space "3" for object "1859"，查詢如下： 

db2 "select tabname,status from syscat.datapartitions where tbspaceid =3 and tableid=1859" 

沒有輸出，懷疑是分區(qū)表的某個分區(qū)壞了，查詢如下： 

db2 "select tabname,DATAPARTITIONNAME from syscat.datapartitions where tbspaceid=3 and PARTITIONOBJECTID=1859" 

輸出如下： 

NXXXXTRFH PART201707 

可以判斷是這個分區(qū)出現(xiàn)壞頁。

查詢該表的狀態(tài)，正常：

db2 "select tabname,status,tbspaceid,tableid from syscat.tables where tabname='NXXXXTRFH'" 

從該表查詢數(shù)據(jù)，正常： 

db2 "select * from dbnpsh. NXXXXTRFH fetch first 10 rows only" 

所以說數(shù)據(jù)庫的壞頁比較復雜，有時候壞頁導致整個表故障，而本次，表面上查看起來，表數(shù)據(jù)一切正常。當跑報表訪問到特定的頁時才報出故障。

嘗試通過load from cursor的方法把壞頁的表分區(qū)的數(shù)據(jù)導出來，和報表查詢語句報同樣的錯誤：

嘗試通過export導出數(shù)據(jù)： 

db2 "export to /db2/archlog/npsh/NXXXXTRFH_PART201707.ixf of ixf select * from db2npsh.NXXXXTRFH_PART201707" 

導出hang住,兩個小時后，導出400多萬數(shù)據(jù)，出現(xiàn)同樣的報錯，而且數(shù)據(jù)量明顯不對

收集所有的日志信息，發(fā)送給IBM800協(xié)助進行分析問題。 

db2support . -d npsh -c -s 

經(jīng)分析，IBM二線確認出現(xiàn)數(shù)據(jù)庫壞頁，建議使用db2dart導出表數(shù)據(jù)：

四、數(shù)據(jù)修復步驟

下面是數(shù)據(jù)找回的過程：

卸載表分區(qū)

由于該表大小達到30G，嘗試將表分區(qū)卸載下來單獨導出： 

db2 alter table dbnpsh.NXXXXTRFH detach partition PART201707 into NXXXXTRFH_PART201707 

卸載成功

db2dart準備工作

執(zhí)行db2dart之前，需要準備兩點：

1、斷開所有數(shù)據(jù)連接 

db2 force applicaitons all 

2、擴容dump目錄至能夠放下整個分區(qū)的數(shù)據(jù)

db2dart導出數(shù)據(jù)

db2dart導出數(shù)據(jù)

開始執(zhí)行db2dart導出數(shù)據(jù)： 

db2dart npsh /DDEL  

然后輸入：1859,3,0,999999

（四個參數(shù)的意義分別為：對象id，表空間id，起始頁號，導出總頁數(shù)）

IBM建議導出總頁數(shù)設置為999999頁

db2dart操作執(zhí)行2小時，發(fā)現(xiàn)導出的頁數(shù)已經(jīng)達到999998，懷疑導出的頁數(shù)超過設置的999999上限?？磥鞩BM給的建議也不是完全準確。

將頁數(shù)改為99999999，重新執(zhí)行db2dart導出（需要先刪除之前導出的dart目錄）： 

db2dart npsh /DDEL  

然后輸入：1859,3,0,99999999

歷時三個小時后，導出成功，總共導出1100000多頁。

導出文件名默認TS3T1859.DEL。

將dart出來的數(shù)據(jù)放入臨時表

新建臨時表NXXXXTRFH_PART20170702，注意指定的表空間要和NXXXXTRFH主表保持一致。

將dart出的數(shù)據(jù)導入到臨時表： 

db2 -v "LOAD FROM TS3T1859.DEL of del INSERT INTO DB2NPSH.NXXXXTRFH_PART20170702 NONRECOVERABLE" 

導入出現(xiàn)“字段類型不匹配”的報錯，經(jīng)過排查，是由于該表包含DBCLOB大字段，這種字段dart命令無法導出。查詢原表，發(fā)現(xiàn)該字段為空，慶幸不會丟失大字段數(shù)據(jù)，但是由于數(shù)據(jù)文件和表結構不匹配，導入成了一個問題。

有兩種方案解決這個問題：

***，編輯數(shù)據(jù)文件，定位到大字段那一列，插入一個逗號，即插入一列空列。

第二，新建不包含大字段列的表，導入數(shù)據(jù)后再添加大字段。

新建NXXXXTRFH_PART20170703不包含dbclob列，導入數(shù)據(jù)： 

db2 -v "LOAD FROM TS3T1859.DEL of del INSERT INTO DB2NPSH.NXXXXTRFH_PART20170703 NONRECOVERABLE"  
Number of rows read = 23771029  
Number of rows skipped = 0  
Number of rows loaded = 23770943  
Number of rows rejected = 86  
Number of rows deleted = 0  
Number of rows committed = 23771029 

添加列 

db2 "alter table db2npsh.NXXXXTRFH_PART20170703 add column URL DBCLOB(2048) LOGGED NOT COMPACT" 

執(zhí)行成功。將臨時表掛載到主表上

將臨時表掛載到主表上： 

db2 "alter table dbnpsh.NXXXXTRFH attach partition PART201707 starting ('20170701') ending ('20170731') from DB2NPSH.NXXXXTRFH_PART20170703" 

掛載失?。?nbsp;

SQL20408N Table "DB2NPSH.NXXXXTRFH_PART20170703" cannot be attached to   
table "DBNPSH.NXXXXTRFH" because column "PAYEENM" of the source table and   
its associated column "URL" of the target table do not match. Reason code = "8". SQLSTATE=428GE 

經(jīng)分析，原因是臨時表的列順序和主表不一致。

解決方法：

將03臨時表的數(shù)據(jù)通過指定列的方式insert到02臨時表： 

db2 -v "INSERT INTO DB2NPSH.NXXXXTRFH_PART20170702 SELECT MSGID,INSTGBKID,MSGCD,SEQNB,INSTGDRCTPTY,BIZTYP,BIZKIND,SYSCD,REGTIME,TRANCHNLTYP,CREDTTM,INSTDDRCTPTY,INSTDPTY,RMK ,PAYERNM,PAYERDPSTBKNM,DBTRDPSHDL,PAYERTELE,PAYERACCTNO,PAYERACCTYP,PWD ,PYMTAGRMT,AUTHPYMTBIZKIND,PTCID,URL,PAYEENM,CDTRDPSHDL,PAYEEDPSTBKID,PAYEEDPSTBKNM,PAYEEACCTNO,ACCTLTD,AGRINEFFCTVDT,AGREFFCTVDT,SNGLTXAMTLMT,ORIGMSGID,CSTMRNB,CDTRCSTMRID,DLTTLCNT,DAYAMTUPPERLMT,CURCD,MSLTTLCNT,MTHAMTUPPERLMT,MAGETYP,ACQFEE,CLRDATE,BIZPRCSCD,BIZRJCTCD,BIZRETSTS,RJCTRESN,BIZSTS,CTRLIND,BIZBIGTYP,ADDINFO1,ADDINFO2,ADDINFO3,ADDINFO4,ADDTBNM,SIGNATURE,TRADEFLAG,RPLIRACCT,RPLIRNM,RPLIRDPSNM,RPLIRDPSHDL,RPLIRACCTTP,QRISTACCT,QRISTNM,QRISTPTYNM,QRISTPTYHDL FROM DB2NPSH.NXXXXTRFH_PART20170703" 

將02臨時表掛載到主表： 

db2 "alter table dbnpsh.NXXXXTRFH attach partition PART201707 starting ('20170701') ending ('20170731') from DB2NPSH.NXXXXTRFH_PART20170702" 

掛載成功 

SQL3601W The statement caused one or more tables to automatically be placed   
in the Set Integrity Pending state. SQLSTATE=01586 

一致性檢查

進行一致性檢查： 

db2 set integrity for dbnpsh.NXXXXTRFH immediate checked 

執(zhí)行大概十分鐘，成功。 

DB20000I The SQL command completed successfully. 

數(shù)據(jù)量確認

查詢201707分區(qū)的數(shù)據(jù)量： 

db2 "select count(*) from DBNPSH.NXXXXTRFH where CLRDATE>='20170701' and CLRDATE<='20170731'" 

導入數(shù)據(jù)總條數(shù)：23770943

原數(shù)據(jù)條數(shù)： 

db2 "select count(*) from DB2NPSH.NXXXXTRFH_PART201707" 

原數(shù)據(jù)總條數(shù)：23771388

損壞的數(shù)據(jù)條數(shù)：23771388-23770943=445條 

至此，數(shù)據(jù)恢復完成，找回23770943條數(shù)據(jù)，損壞445條。