标签：需要 source class -- 根据 http 输入 结构 方式
数据库最严重的故障莫过于数据库损坏。数据库坏页是数据库损坏的一种，如果数据库中有数据页出现损坏，在没有访问到坏页时，数据库可以正常提供服务，当使用到坏页所在的表，有可能导致数据库的崩溃。
导致数据库出现坏页的可能性有很多，比如突然的掉电、主机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之前，需要准备两点：
1、断开所有数据连接
db2 force applicaitons all
2、扩容dump目录至能够放下整个分区的数据
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。
新建临时表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"
挂载失败：
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条。
标签：需要 source class -- 根据 http 输入 结构 方式
原文地址：http://www.cnblogs.com/liujiacai/p/7454300.html
