一起8TB asm磁盘组元数据损坏修复记录

作者简介：王旭，在数据库管理方面拥有10多年经验。精通主流数据库系统，在企业数据库管理、性能优化、架构设计和高可用性能解决方案方面拥有丰富得实践经验。目前拥有（ORACLE ACE、MYSQL OCP、PG ACE、PGCA、PGCE、PGCM）等数据库认证。

环境

oracle 11.2.0.4 rac 双节点 数据量：磁盘组8TB, 数据库所使用7TB 左右

背景

• 昨天晚上9点过，一朋友找到我，说加完磁盘到一个磁盘组中，再添加数据文件，磁盘组直接挂掉，asm alert日志出现大量的ORA-15196报错，如下：

ORA-15196:invalid AsM block header [kfc.c:26368] [endian kfbh][21474836571[256][0 !- 1]

• 从上面的报错我们可以看到几个关键信息：

1） arb进程导致，说明在reblance过程中出现；
2） kfc.c: 26368,说明是这个模块的对应这个行的代码出现异常（oracle内部）
3） 出错的磁盘组EMRDATA，编号=3，dsk=9，blk=256，au=0

通过这些信息，我们可以初步得出结论，在当前的11gasm中，这个磁盘组的au是》=4的,而不是au=1m;

具体分析和处理

• 查询目前的磁盘组和磁盘信息

QL> select group_number||'_'||disk_number as dno,name,failgroup,failgroup_type,path,create_date,mount_date,mount_status,header_status,state,os_mb,total_mb,free_mb,voting_file,repair_timer rpt from v$asm_disk order by 1;

DNO   NAME          FAILGROUP     FAILGRO PATH                                     CREATE_DA MOUNT_DAT MOUNT_S HEADER_STATUS   STATE           OS_MB   TOTAL_MB    FREE_MB V    RPT
----- ------------- ------------- ------- ---------------------------------------- --------- --------- ------- --------------- ---------- ---------- ---------- ---------- - ------
0_0                               REGULAR dev/asm-data008                         04-SEP-20 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_1                               REGULAR dev/asm-data009                         04-SEP-20 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_10                              REGULAR dev/asm-data016                         10-DEC-22 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_11                              REGULAR dev/asm-data014                         10-DEC-22 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_12                              REGULAR dev/asm-data011                         10-DEC-22 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_13                              REGULAR dev/asm-data013                         10-DEC-22 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_14                              REGULAR dev/asm-data012                         10-DEC-22 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_15                              REGULAR dev/asm-data010                         04-SEP-20 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_2                               REGULAR dev/asm-data007                         04-SEP-20 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_3                               REGULAR dev/asm-data006                         04-SEP-20 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_4                               REGULAR /dev/asm-data019                         18-JUN-25 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_5                               REGULAR /dev/asm-data005                         04-SEP-20 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_6                               REGULAR /dev/asm-data017                         10-DEC-22 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_7                               REGULAR /dev/asm-data018                         10-DEC-22 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_8                               REGULAR /dev/asm-data004                         04-SEP-20 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
0_9                               REGULAR /dev/asm-data015                         10-DEC-22 18-JUN-25 CLOSED  MEMBER          NORMAL         512000          0          0 N      0
1_0   CRS_0000      CRS_0000      REGULAR /dev/asm-ocrvode01                       04-SEP-20 18-JUN-25 CACHED  MEMBER          NORMAL          10240      10240       9930 Y      0
...

• 使用循坏kfed读取找到对应的是哪个盘，然后再用kfed读取损坏的au的某个块

//从上面可以看出，目前的这个块已经坏了，那么这个块是什么呢？ //前面说到我判断他是au为4的大小，那么这里它肯定是AT块了，现在就进一步分析这个AT块有没有分配AU和十六进制的文件号，如果有那就麻烦了，还需要去定位虚拟文件，找到文件分布再手工构造这个块。运气不错，256前的255、254这些块恰好是V=0，说明没有分配到这里来，通过fsty也能看出来（由于未截完图，这里大概描述下）；

• 将前面的块读取出来一个来构造

• 将构造的块恢复进去

• 恢复完成后，磁盘组可正常挂载

总结

• asm元数据at损坏的情况不多，但出现了往往比较考研dba的专业知识，只有对oracle的原理掌握通透，熟悉底层逻辑，出现问题才能解决，不然就只能靠备份或者容灾去恢复了。
• 本篇文章主要是讲解思路，分两种情况，1、未使用的  2、使用的 ，文章是第一种情况，那么出现第二种情况怎么构造呢？那就只有用另外的方法，需要读取更多的au和块来整理了构造填写了。
• 技术再高，也怕挨刀，做好备份才是王道，技术不够，有备份，时间也可以来凑；
• 很多人以为做了rac，只备份oracle就完了，实际上不知道asm元数据也是数据库，它的磁盘关键信息我们也是需要备份的。懂得都懂。
• 经过30多分钟的处理，问题得到了解决。将8个T的磁盘组挂载了起来，恢复了业务。