數據庫壞頁！一次生產故障處理的詳細記錄
斷電、硬件故障……這些都可能導致數據庫壞頁，進而引發數據庫崩潰。本文記錄了一次生產環境中 Db2 數據庫壞頁的故障處理，詳細分享了如何恢復絕大部分數據，并恢復數據庫的正常運行。
前言
數據庫最嚴重的故障莫過于數據庫損壞。數據庫壞頁是數據庫損壞的一種，如果數據庫中有數據頁出現損壞，在沒有訪問到壞頁時，數據庫可以正常提供服務，當使用到壞頁所在的表，有可能導致數據庫的崩潰。
導致數據庫出現壞頁的可能性有很多，比如突然的掉電、主機down機，或者存儲、磁盤的故障等等。
當數據庫出現壞頁時，首先使用操作系統命令判斷是否出現硬件故障，修復硬件故障后，可以嘗試使用"db2 restart db dbname"命令讓數據庫執行崩潰恢復，這種方法有可能恢復數據庫的正常。如果不適用與上述方法，那么***的辦法就是從備份恢復數據庫。
如果無法從備份恢復，那么在數據庫可以連接的情況下，可以采用db2look導出表結構和export導出數據的方法來重建數據庫。當然對于損壞的表，只能使用db2dart工具離線導出這些表的數據，處于壞頁上的數據庫極有可能丟失了。
如果數據庫無法連接了，只能使用db2dart離線導出整個數據庫的數據。導出數據之后，剩下的就是重建庫并且導入數據了。
本文記錄了一次生產環境中數據庫頁頭的損壞的數據庫壞頁故障，經過一波三折的修復過程，最終恢復了絕大部分數據，恢復了數據庫的正常運行。
環境介紹
操作系統版本 AIX 6100-07-04-1216
數據庫版本 DB2 v9.7.0.7
該數據庫比較大，大概2.2T，出現壞頁的表數據量也比較大，大概30G。
一、問題發現
業務人員查詢XXX數據庫的某個報表查詢，出現如下報錯：
二、初步分析
查看該報錯的解釋：
- db2 "? sql1655c"
查看數據庫的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.
同時，也發現dump目錄下生成FODC_BadPage的文件。
三、進一步分析
嘗試定位出現壞頁的表：
根據db2npsh.nfy 日志中的信息table space "3" for object "1859"，查詢如下：
- db2 "select tabname,status from syscat.datapartitions where tbspaceid =3 and tableid=1859"
沒有輸出，懷疑是分區表的某個分區壞了，查詢如下：
- db2 "select tabname,DATAPARTITIONNAME from syscat.datapartitions where tbspaceid=3 and PARTITIONOBJECTID=1859"
輸出如下：
- NXXXXTRFH PART201707
可以判斷是這個分區出現壞頁。
查詢該表的狀態，正常：
- db2 "select tabname,status,tbspaceid,tableid from syscat.tables where tabname='NXXXXTRFH'"
從該表查詢數據，正常：
- db2 "select * from dbnpsh. NXXXXTRFH fetch first 10 rows only"
所以說數據庫的壞頁比較復雜，有時候壞頁導致整個表故障，而本次，表面上查看起來，表數據一切正常。當跑報表訪問到特定的頁時才報出故障。
嘗試通過load from cursor的方法把壞頁的表分區的數據導出來，和報表查詢語句報同樣的錯誤：
嘗試通過export導出數據：
- db2 "export to /db2/archlog/npsh/NXXXXTRFH_PART201707.ixf of ixf select * from db2npsh.NXXXXTRFH_PART201707"
導出hang住,兩個小時后，導出400多萬數據，出現同樣的報錯，而且數據量明顯不對
收集所有的日志信息，發送給IBM800協助進行分析問題。
- db2support . -d npsh -c -s
經分析，IBM二線確認出現數據庫壞頁，建議使用db2dart導出表數據：
四、數據修復步驟
下面是數據找回的過程：
卸載表分區
由于該表大小達到30G，嘗試將表分區卸載下來單獨導出：
- db2 alter table dbnpsh.NXXXXTRFH detach partition PART201707 into NXXXXTRFH_PART201707
卸載成功
db2dart準備工作
執行db2dart之前，需要準備兩點：
1、斷開所有數據連接
- db2 force applicaitons all
2、擴容dump目錄至能夠放下整個分區的數據
db2dart導出數據
db2dart導出數據
開始執行db2dart導出數據：
- db2dart npsh /DDEL
然后輸入：1859,3,0,999999
（四個參數的意義分別為：對象id，表空間id，起始頁號，導出總頁數）
IBM建議導出總頁數設置為999999頁
db2dart操作執行2小時，發現導出的頁數已經達到999998，懷疑導出的頁數超過設置的999999上限。看來IBM給的建議也不是完全準確。
將頁數改為99999999，重新執行db2dart導出（需要先刪除之前導出的dart目錄）：
- db2dart npsh /DDEL
然后輸入：1859,3,0,99999999
歷時三個小時后，導出成功，總共導出1100000多頁。
導出文件名默認TS3T1859.DEL。
將dart出來的數據放入臨時表
新建臨時表NXXXXTRFH_PART20170702，注意指定的表空間要和NXXXXTRFH主表保持一致。
將dart出的數據導入到臨時表：
- db2 -v "LOAD FROM TS3T1859.DEL of del INSERT INTO DB2NPSH.NXXXXTRFH_PART20170702 NONRECOVERABLE"
導入出現“字段類型不匹配”的報錯，經過排查，是由于該表包含DBCLOB大字段，這種字段dart命令無法導出。查詢原表，發現該字段為空，慶幸不會丟失大字段數據，但是由于數據文件和表結構不匹配，導入成了一個問題。
有兩種方案解決這個問題：
***，編輯數據文件，定位到大字段那一列，插入一個逗號，即插入一列空列。
第二，新建不包含大字段列的表，導入數據后再添加大字段。
新建NXXXXTRFH_PART20170703不包含dbclob列，導入數據：
- 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"
執行成功。將臨時表掛載到主表上
將臨時表掛載到主表上：
- 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
經分析，原因是臨時表的列順序和主表不一致。
解決方法：
將03臨時表的數據通過指定列的方式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
執行大概十分鐘，成功。
- DB20000I The SQL command completed successfully.
數據量確認
查詢201707分區的數據量：
- db2 "select count(*) from DBNPSH.NXXXXTRFH where CLRDATE>='20170701' and CLRDATE<='20170731'"
導入數據總條數：23770943
原數據條數：
- db2 "select count(*) from DB2NPSH.NXXXXTRFH_PART201707"
原數據總條數：23771388
損壞的數據條數：23771388-23770943=445條
至此，數據恢復完成，找回23770943條數據，損壞445條。
