一聚教程网:一个值得你收藏的教程网站

热门教程

oracle中一次dataguard坏块的修复

时间:2022-06-29 09:29:24 编辑:袖梨 来源:一聚教程网

客户有个11g的active dataguard库,mrp进程停了,看alertlog,可以看到有关ora-7445[kdxlin]的报错:

cat alert*.log
....
Exception [type:SIGSEOV,Address not mapped to object] [ADDR:0xC] |PC:0x96504C7,kdxlin()+4153][flags: 0x0,count:1]
Errors in le /aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/trace/partsm_pr18_21343.trc (incident=70353):
ORA-07445: exception encountered: core dump (kdxlin()+4153) [SIGSEGV] [ADDR:0xC] |PC:0x96504C7][Address not mapped to object][]
Incident details in: /aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/incident/incdir_70353/mydbsid_pr18_21343_i70353.trc
Use ADRCI or Support Workbench to package the incident.
 
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0xC][PC:0x96504C7,kdxlin()+4153][flags:0XO,count:1]
Incidenl 70353 created, dump file/aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/incident/incdir_70353/mydbsid_pr18_21343_i70353.trc
ORA-07445: exception encountered: core dump (kdxlin()+4153) [SIGSEGV] [ADDR:0xC] |PC:0x96504C7][Address not mapped to object][]
...

cat /aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/incident/incdir_70353/mydbsid_pr18_21343_i70353.trc
...
Error 607 in redo applicalion callback
Dump of change vector
Typ:2 CLS:1 APN:5 DBA0x2598d645 OBJ:3S3792 SCN:0x0960.99d2655e SEQ:1 OP:10.2 ENC:0 RBL:0
index redo(kdxlin):insert leaf row
KTB Redo
op:0x01 ver:0x01
compat bit:4(post-11) padding:1
op:F xid:0x0001.01a.010d8f34 uba:0x00dc8e3.6bf5.20
REDO: SINGLE/NONKEY/--
itl:3, sno:255, row size 23
insert key:(14):05 c4 02 4e 31 4f 07 78 74 0b 09 11 27 29
nonkey (length: 5):
fb: --H-FL-- lb:0x0 cc:1
(2).01 80
Block after image is corrupt:
buffer tsn: 5 rdba:0x2598d645(1024/630773317)
scn:0x960.99d10d33 seq:0x01 flg:0x04 tail:0x0d330601
frmt:0x02 chkval:0xa1ae type:0x06=trans data
Hex dump of currupt header 3=CHKVAL
...
从trace中,我们可以看到这个dataguard上有坏块,坏块是在(file#5, block# 630773319)中。

先说一下对于坏块的处理:

1. 主库:

■ 如果是在索引块上,重建索引
■ 如果是在数据块上,且存在备份,用备份做blockrecover
■ 如果是在空块上,建一个表,填充这个块,填充时就会自动格式化对应的坏块。可以参考我以前写过的这里。
■ 如果是11gADG,物理坏块将触发ABMR(Automatic Block Recover),oracle将通过ABMR自动修复坏块。
■ 如果是逻辑坏块,且配置了DB_LOST_WRITE_PROTECT+DB_BLOCK_CHEKING,将自动修复。(参考Doc ID 1302539.1)
■ 如果ABMR和lost write protection没有触发,将dataguard的文件rman备份,再restore到主库,再recover。

2.备库:

■ 首先考虑ABMR和DB_LOST_WRITE_PROTECT,是否自动修复
■ 利用备份,做blockrecover
■ 将主库的文件rman备份,再restore到主库,再recover。

由于是逻辑坏块,ABMR没有被触发。那么我们常规的做法是上面的第2和第3,可是,问题来了。

尝试第3条,将主库的文件拷贝到备库,发现这个发生坏块的库是在上海,根据两地三中心的架构,这个是个远程dataguard。拷贝文件和传输文件需要比较多的时间。那么究竟需要多少时间?我发现这个坏块(file#5, block# 630773319)是在一个bigfile tablespace上,而这个tablespace的datafile,已经到达了7T的大小!orz 给跪了……

尝试第2条,发现主库和local dataguard都在深圳,这个库在上海,而备份软件是在深圳的dataguard上备份的。远程的机器上没有agent,网络也没有通。再次跪。

好了,传统的方法都不行,开始思考非常规的方法,和同事进行头脑风暴了:

1. 既然是备库索引上的坏块,那么我主库重建索引,备库也就重建索引了。
>>可是现在mrp停在前面的一步,在没有过去这个点之前,是一直卡在这里,不会apply后续的日子,也就不会重复主库上的重建索引的操作。

2.既然已经找到对应的坏块,但是有不能进行blockrecover,那么将好块dd出来,再dd到坏块中。
>>由于使用是asm,要做这种操作的话,需要将数据文件先cp到文件系统,再在文件系统上做dd,在将块传输到上海。可惜7T的asm文件无法cp出来。

3.将这个坏块dd成物理坏块,利用ABMR恢复。
>>做dd也是有同2的问题,7T的asm文件无法cp出来。

4. 用bbed来修改,也涉及到cp 7T的asm文件。


这个时候,客户提出了一种解决方案,用增量备份,然后在做recover datafile 5 noredo;

这种方案之前都没有试过,我心里也没底,所以我在我自己的测试机器上测试了这种方案,发现还是无法修复坏块。但是客户坚持想尝试一下,没想到,成功了!

没想到增量备份+recover datafile noredo,这种追dataguard缺少归档日志的方式,也可以修复坏块!(增量备份的大小只有几个G,传输很方便。)

把这个好消息告诉了同事,同事指出,这个方法其实存在偶然性,因为这种方式,要求在mrp停掉的那个scn之后,坏块对应的主库上的块,已经被修改过了。这样才能包含在主库增量备份中。

一语惊醒梦中人,我在测试机上测试失败的原因,正是我在主库上没有修改对应的记录,即备库坏块对应在主库上的块,没有被修改过。所以也就不会包含在增量备份中了。

所以,多了这种方法之后,我们又可以头脑风暴,如果后续还发生这种情况,怎么样使得主库没有修改的块,发生变动……如update对应的块,如rebuild index online……

另外,再说一下:珍惜生命,远离bigfile tablespace。

热门栏目