一次dataguard坏块的修复

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

从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。

参考
ABMR: How to test Automatic Block Recover Feature (Doc ID 1266059.1)
ABMR: How to test Automatic Block Recover Feature with ASM setup (Doc ID 1510090.1)
Best Practices for Corruption Detection, Prevention, and Automatic Repair – in a Data Guard Configuration (Doc ID 1302539.1)

相关文章

3条评论

  1. 》看到这个dataguard上有坏块,坏块是在(file#5, block# 630773319)中。

    什么确定是这个坏块。
    SYS@book> @ &r/16to10 2598d645
    16 to 10 DEC
    ————
    630773317

    我还有一个疑问,这个时候是否update 触发这个索引对应块修改可以修复这个问题。

  2. 坏块是逻辑坏块,就算update了,也还是不能触发ABMR。

  3. 可以用dbms_diskgroup 包 在standby端把坏块拷贝出来 处理好再拷贝入asm当中? 是否可行,小荷大师

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据