wangweilong
作者wangweilong2017-08-30 15:40
数据库管理员, 某大

Db2数据库一次生产故障详细记录---数据库坏页

字数 6076阅读 6103评论 5赞 45

前言

数据库最严重的故障莫过于数据库损坏。数据库坏页是数据库损坏的一种,如果数据库中有数据页出现损坏,在没有访问到坏页时,数据库可以正常提供服务,当使用到坏页所在的表,有可能导致数据库的崩溃。

导致数据库出现坏页的可能性有很多,比如突然的掉电、主机down机,或者存储、磁盘的故障等等。

当数据库出现坏页时,首先使用操作系统命令判断是否出现硬件故障,修复硬件故障后,可以尝试使用"db2 restart db dbname"命令让数据库执行崩溃恢复,这种方法有可能恢复数据库的正常。如果不适用与上述方法,那么最好的办法就是从备份恢复数据库。

如果无法从备份恢复,那么在数据库可以连接的情况下,可以采用db2look导出表结构和export导出数据的方法来重建数据库。当然对于损坏的表,只能使用db2dart工具离线导出这些表的数据,处于坏页上的数据库极有可能丢失了。

如果数据库无法连接了,只能使用db2dart离线导出整个数据库的数据。导出数据之后,剩下的就是重建库并且导入数据了。

本文记录了一次生产环境中数据库页头的损坏的数据库坏页故障,经过一波三折的修复过程,最终恢复了绝大部分数据,恢复了数据库的正常运行。

环境介绍

操作系统版本 AIX 6100-07-04-1216
数据库版本 DB2 v9.7.0.7
该数据库比较大,大概2.2T,出现坏页的表数据量也比较大,大概30G。

一、问题发现

业务同事查询XXX数据库的某个报表查询,出现如下报错:

1.png

1.png

二、初步分析

查看该报错的解释:
db2 "? sql1655c"

2.png

2.png

查看数据库的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的方法把坏页的表分区的数据导出来,和报表查询语句报同样的错误:

3.png

3.png

尝试通过export导出数据:
db2 "export to /db2/archlog/npsh/NXXXXTRFH_PART201707.ixf of ixf select * from db2npsh.NXXXXTRFH_PART201707"
导出hang住,两个小时后,导出400多万数据,出现同样的报错,而且数据量明显不对

4.png

4.png

收集所有的日志信息,发送给IBM800协助进行分析问题。
db2support . -d npsh -c -s

经分析,IBM二线确认出现数据库坏页,建议使用db2dart导出表数据:

5.png

5.png

四、数据修复步骤

下面是数据找回的过程:

卸载表分区

由于该表大小达到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页

6.png

6.png

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"
挂载失败:
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条。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

45

添加新评论5 条评论

atpeace331atpeace331数据库管理员, 银行
2017-09-13 15:59
db2dart 的缺陷就是不能修复 LOB列的数据,如果原表LOB列数据不为空的话,应该如何解决这个问题呢

jtni@wangweilong 为什么没有判断是逻辑坏页还是物理坏页 还有建临时表为啥必须跟主表飚空间一致?不应该跟该分区的表空间一致吗?

2018-09-28 10:07

wangweilong@atpeace331 如果表里有lob字段,确实不能使用db2dart命令导出来,目前也没有其他好的办法。所以,建议对于大字段,最好使用inline的lob方式存储,这种方式可以使用db2dart导出。

2017-09-15 13:48
mountainsunmountainsun数据库运维工程师, 吴江银行
2017-09-05 09:26
多谢分享,看了感觉很不错,思路清晰,解决方案很明确。
penguin23penguin23系统运维工程师, 广州佳杰科技有限公司
2017-09-04 21:31
DB2的报错,很多都莫名奇妙的。
Scott_jinScott_jin数据库管理员, 环境
2017-09-01 15:41
不错的处理过程。 如果是核心库那就蛋疼了
baizhaoxianbaizhaoxian容灾备份管理工程师, 无
2017-08-30 17:22
实用,明理化,不错,谢谢分享
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广