一则非常巧合的ORA-15042恢复

点击蓝字 关注我们

今天跟大家分享一个ASM磁盘组损坏的案例，此案例来自于一个网友。由于是保密客户，不能拿到数据，所以这里只是在自己的环境中模拟此现象并给出解决方案。

从Oracle 10G中，Oracle推出ASM（自动存储管理）功能，用于替换基于主机的存储管理软件，使得Oracle Rac运行不在依赖于第三方的存储管理软件（如hacmp，sfrac）。在10G中，ASM的功能和稳定性就还不完善，并没有大规模的被使用。但是在11G版本中,ASM已经大规模被使用，瞬间成为集群的核心存储管理解决方案。同时ASM这个黑匣子也逐渐的被大家认识，今天我们就给大家分享一个ASM磁盘组不能挂载的案例。

ASM磁盘组有三种冗余方式：External Redundancy、Normal Redundancy、High Redundancy。其中的冗余机制这里就不过多介绍了，拥有冗余的磁盘组就可以高枕无忧了吗？肯定不是，冗余的机制只能保证部分故障的解决，还不足以让我们高枕无忧，就如我们今天的分享案例，哪怕你有normal的冗余方式，也只能事出无奈、束手无策，特别是在一些OLAP系统中，几十T的数据很正常，当故障来临时，哪怕通过备份来还原，那么这个时间也是无法容忍的。唯有对ASM的原理足够的了解，才能让我们在故障时，通过一些非常规的手段修复。

ASM跟普通文件系统一样，有自己的元数据，并且ASM的元数据库是可以直接通过KFED来查看和编辑的，今天我们用到的就是PST元数据，下面我们简单描述一下：

PST对于ASM非常重要，在读取其他ASM metadata之前会先检查PST,当mount diskgroup时，GMON进程会读取diskgroup中所有磁盘去找到和确认PST，通过PST可以确认哪些磁盘是可以ONLINE使用的,哪些是OFFLINE的。

PST位于磁盘的第一个au上，但并不是每块磁盘上都有PST。磁盘组镜像的不同，PST的个数也不同，如下：

• External Redundancy一般有一个PST

• Normal Redundancy至多有个3个PST

• High Redundancy 至多有5个PST

下面有请我们今天的主角出场：

NORMAL磁盘组中有1个failgroup意外offline(如现在市面上的一体机1个存储节点意外重启)，在这个failgroup恢复回来重新成功online之前，另外一个failgroup中有一块磁盘损坏了，此时悲剧就发生了，即使被offline的failgroup还原回来，也不能mount磁盘组。因为我们之前介绍的ASM重要元数据PST认为这些盘的状态不是可正常访问的。

1、构建一个NORMAL冗余的磁盘组，有3个failgroup，每个fg有2块盘：

SQL> select GRPNUM_KFDSK,NUMBER_KFDSK,MODE_KFDSK,FAILNAME_KFDSK,PATH_KFDSK from x$kfdsk where GRPNUM_KFDSK=2;
 
GRPNUM_KFDSK NUMBER_KFDSK MODE_KFDSK FAILNAME_KFDSK       PATH_KFDSK
------------ ------------ ---------- -------------------- --------------------
           2            0        127 FG2                  /dev/asm-test-diske
           2            1        127 FG2                  /dev/asm-test-diskf
           2            2        127 FG1                  /dev/asm-test-diskc
           2            3        127 FG1                  /dev/asm-test-diskd
           2            4        127 FG3                  /dev/asm-test-diskg
           2            5        127 FG3                  /dev/asm-test-diskh

为了便于观察恢复效果，跟踪某条记录的变化，在offline primary extent所在磁盘后，更新这条数据，然后破坏其secondary extent所在磁盘，最后验证该事务是否丢失。这里手动创建一张rescureora的测试表，并查看其中一行记录物理存放位置。

SQL> select object_id,object_name,
  2         dbms_rowid.rowid_block_number(rowid) block#,
  3         dbms_rowid.rowid_relative_fno(rowid) file#
  4    from sys.rescureora where rownum=1;
 
OBJECT_ID OBJECT_NAME                                  BLOCK#      FILE#
---------- ---------------------------------------- ---------- ----------
        20 ICOL$                                           131          5

通过脚本找到数据块与ASM磁盘的映射关系，由于是normal冗余，此处会看到两副本，LXN_KFFXP为0的是primary extent在1号disk上，为1的是secondary extent在4号disk上，稍后我们就模拟offline 1号disk所在fg，并且破坏4号盘。

SQL> @asm_block
Enter value for block: 131
Enter value for file_number: 256
Enter value for file_type: DATAFILE
Enter value for filename: TEST.256.1034246527
 
GROUP_KFFXP  LXN_KFFXP   AU_KFFXP DISK_KFFXP  PXN_KFFXP
----------- ---------- ---------- ---------- ----------
          2          1         24          4          3
          2          0         30          1          2

2、通过GMON的日志文件来分析PST位置

从gmon trace可以发现，该磁盘组PST在0、2、4号磁盘上。通过kfed也可以验证：

=