ock.blk: 0 ; 0x004: T=0 NUMB=0x0 kfbh.block.obj: 0 ; 0x008: TYPE=0x0 NUMB=0x0 kfbh.check: 0 ; 0x00c: 0x00000000 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 CE: (0x0x400417ee4e0) group=1 (DATA) obj=2 (disk) blk=1 hashFlags=0x0002 lid=0x0002 lruFlags=0x0000 bastCount=1 redundancy=0x11 fileExtent=-2147483648 AUindex=0 blockIndex=1 copy #0: disk=2 au=0 BH: (0x0x40041795000) bnum=4586 type=reading state=reading chgSt=not modifying flags=0x00000000 pinmode=excl lockmode=share bf=0x0x40041400000 kfbh_kfcbh.fcn_kfbh = 0.0 lowAba=655.8572 highAba=0.0 last kfcbInitSlot return code=null cpkt lnk is null 大家知道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！
|