Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

这周折腾了2天的时间帮客户成功恢复了一套近1.4TB的10.2.0.5 RAC(ASM). 该库在3月4号直接crash了。

大家可以看到,该库在开始报错读取redo,controlfile报错,本质原因是DISKGROUP dismount了,信息如下:

数据库实例挂了之后,我们来看下ASM实例的alert log信息,如下:

大家可以看到,ASM报了一个ORA-15081错误,在该错误之前是报对其中一个盘/dev/raw/raw5的IO操作错误。
细心的朋友可以看到,这里由于IO 操作异常后,该disk被offline了。最后磁盘组无法mount。

我们测试使用kfed read无法读取该disk,dd也无法操作。但是却可以直接dd 该disk对应的物理盘。

磁盘组无法mount,从其中trace来看显然是磁盘头损坏,如下:

大家知道Oracle ASM 10.2.0.5版本开始会对ASM disk header 进行自动备份,如果如果仅仅是盘头
损坏那么恢复是很easy的。但是其实并不是这么简单,通过dd判断,该盘的前面几个block其实被损坏。

最后我们通过ODU 直接将数据文件从磁盘拷贝到文件系统,然后起库,最后完成整个恢复过程。

备注:在恢复过程中,发现ODU无法直接拷贝test201402.dbf 这样的文件,然而通过检查

asm alias directory发现,其实是完好的,这里可能odu处理还有点小问题,我们通过手工将该元数据

的AU 读取出来,然后匹配将剩下的文件全部抽取出来了,包括redo,controlfile,直接顺利打开数据库。

不得不说,熊哥的ODU太强大了,秒杀各种Oracle ASM的数据库恢复Case!

    分享到:
18180207355
加Q咨询