12TB ASM RAC磁盘无法mount的案例

网友发的信息，从alert log来看，在手工mount diskgroup的时候报错如下：

Thu Aug 28 10:34:29 2014
WARNING: cache read a corrupted block gn=3 fn=1 blk=263 from disk 1
NOTE: a corrupted block was dumped to /oracle/diag/asm/+asm/+ASM/trace/+ASM_ora_17918.trc
ERROR: cache failed to read gn=3 fn=1  blk=263 from disk(s): 1
ORA-15196: invalid ASM block header [kfc.c:9133] [obj_kfbl] [1] [263] [3 != 1]
System State dumped to trace file /oracle/diag/asm/+asm/+ASM/trace/+ASM_ora_17918.trc
NOTE: cache initiating offline of disk 1  group 3
WARNING: initiating offline of disk 1.4042510639 (DATA_DG_0001) with mask 0x7e 
NOTE: initiating PST update: grp = 3, dsk = 1, mode = 0x15

对于这个错误，是非常常见的了。Oracle MOS也有不少的文档进行描述，本质上其实就是ASM元数据存在异常了。对于Oracle ASM的元数据，我写了一系列的文章，供参考。需要注意的是，有些元数据如果损坏，那么我们可以很容易修复，比如disk header，Disk directory，PST等等。其他的出现问题了，就比较麻烦了。 我们这里简单描述下这个ORA-15196错误的含义：
ORA-15196: invalid ASM block header [1st] [2nd] [3rd] [4th] [5th != 6th]

Argument Meaning 
1st   Function and line number in the code, where the exception is raised  
2nd  Field failing the validation 
3rd   ASM object number stored in the block 
4th   ASM block number stored in the block  
5th   Value associated with field referenced by argument 2  
6th   Expected value for field referenced by argument 2 

根据Oracle MOS 文档的解释，我们这里的这个错误，可以理解为这样一个意思：

Oracle 在执行kfc.c代码的9133行时报错。校验时发现obj_kfbk异常。ASM 对象号为1，存在的block号为263. 发现该block内的值应该是1，而不是3.

这里补充一点，对于asm object，为1标示file directory。这里大家可以参考我之前的一个例子：

SQL> select number_kffxp file#, disk_kffxp disk#, count(disk_kffxp) extents
  2  from x$kffxp
  3  where group_kffxp=1
  4        and disk_kffxp <> 65534
  5  group by number_kffxp, disk_kffxp
  6  order by 1;

     FILE#      DISK#    EXTENTS
---------- ---------- ----------
         1          0          2
         2          1          1
         3          0         21
         3          1         21
         4          0          1
         4          1          1
         5          0          1
         6          0          1
       256          0        241
       256          1        241
       257          0        120
   .........
       263          0         28
       263          1         28
       264          0         11
       264          1         10
       265          1          1

27 rows selected.

上述查询的file信息，其实就的10g版本中asm所涉及的元数据信息，对应关系如下：

file#   1   ---ASM file 1,file directory
file#   2   ---ASM file 2,disk directory
file#   3   ---ASM file 3,active Change Directory(ACD)
file#   4   ---ASM file 4,continuing Operations Directory (COD)
file#   5   ---ASM file 5,template directory
file#   6   ---ASM file 6,alias directory

所以，根据目前了解的信息来看，这里本质上是file directory出现问题了。如果想进一步了解，我们可以分析alert log中提到的trace文件，下面来简单看看，我们搜索关键字来看下比较重要的一段信息：

*** ACTION NAME:() 2014-08-28 10:34:29.920
 
WARNING: cache read a corrupted block gn=3 fn=1 blk=263 from disk 1

*** 2014-08-28 10:34:29.943
OSM metadata block dump:
kfbh.endian:                          0 ; 0x000: 0x00
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            8 ; 0x002: KFBTYP_CHNGDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                    1607 ; 0x004: T=0 NUMB=0x647
kfbh.block.obj:                       3 ; 0x008: TYPE=0x0 NUMB=0x3
kfbh.check:                   152962911 ; 0x00c: 0x091e075f
kfbh.fcn.base:                 49018345 ; 0x010: 0x02ebf5e9
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfracdb.aba.seq:                   1722 ; 0x000: 0x000006ba
kfracdb.aba.blk:                   1606 ; 0x004: 0x00000646
kfracdb.ents:                        21 ; 0x008: 0x0015
kfracdb.ub2spare:                     0 ; 0x00a: 0x0000
。。。。。。
ERROR: cache failed to read gn=3 fn=1  blk=263 from disk(s): 1
  CE: (0x380bd96f8)  group=3 (DATA_DG) obj=1  blk=263
      hashFlags=0x0008  lid=0x0002  lruFlags=0x0000  bastCount=1
      redundancy=0x11  fileExtent=1  locator:  obj=1  blk=1
      blockIndex=7 AUindex=0 AUcount=1 mirror=0
      flags_kfcpba=0x09 copies=1 blockIndex=7 AUindex=0 AUcount=1
      copy #0:  disk=1  au=25
  BH: (0x380fb8ed0)  bnum=2635 type=reading state=reading chgSt=not modifying
      flags=0x00000000  pinmode=excl  lockmode=excl  bf=0x380f2e000
      kfbh_kfcbh.fcn_kfbh = 0.49018345  lowAba=1716.2941  highAba=0.0
      last kfcbInitSlot return code=null cpkt lnk is null ralFlags=0x00000000

这里正是我们报错提到的fn=1 blk=263 。这里的au 25其实是有问题的，可惜这里我忘记保留当时的kfed的记录了。很明显这里kfbh.block.obj的值，Oracle认为应该是1，因为这是file directory的信息，但是上面的type显示又是KFBTYP_CHNGDIR，这显然是不匹配的。

对于这样的case，通常是只能利用DUL或ODU等软件来文件级别的抽取。少数情况下，可以利用Oracle patch asm的脚本进行元数据的修复。

备注：11g开始，Oracle的asmcmd就提供了备份asm元数据的命令，对于一些不稳定的版本，真是强烈建议定期备份一下啊。。。