点击上方蓝字关注我们～

我们的文章会在微信公众号“Oracle恢复实录”和博客网站“rescureora.com” 同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！

今天跟大家分享一个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认为这些盘的状态不是可正常访问的。

构建NORMAL冗余磁盘组

为了便于观察恢复效果，跟踪某条记录的变化，在offline primary extent所在磁盘后，更新这条数据，然后破坏其secondary extent所在磁盘，最后验证该事务是否丢失。

这里手动创建一张rescureora的测试表，并查看其中一行记录物理存放位置。

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

通过GMON日志分析PST位置

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

模拟故障现象

offline fg2

fg2为primary extent所在的failgroup，此时手动offline，模拟生产环境的服务器关机。

SQL> ALTER DISKGROUP TEST offline disks in failgroup fg2;

Diskgroup altered.

此时gmon日志中，会生成最新的PST信息，如下：

更新数据

此处更新数据只是为了最后验证数据的有效性。

手动破坏4号磁盘

这里采用的dd命令，如果在12C中开启afd后，dd命令会自动过滤。

[grid@rescureora1 trace]$ dd if=/dev/zero of=/dev/asm-test-diskg bs=4096 count=1 conv=notrunc1+0 records in1+0 records out4096 bytes (4.1 kB) copied, 0.000306284 s, 13.4 MB/s

故障出现

磁盘组已经无法mount：

通过gmon trace观察此时的PST分布情况：

解决方案

查看PST中的磁盘状态

修改磁盘状态

这里将磁盘0和1的状态值修改为127即可。

挂载磁盘组

PST修复完成，尝试mount磁盘组：

SQL> alter diskgroup test mount force;alter diskgroup test mount force*ERROR at line 1:ORA-15032: not all alterations performedORA-15096: lost disk write detectedORA-15042: ASM disk "4" is missing from group number "2"

这里报写丢失，跟之前的报错已经不一样，此时是由于磁盘组在挂载时做recover报错，那么很简单，跳过recover那一步就可以。

此时报错稍微有些不同，磁盘组在进行recover的时候报错，checkpoint为seq=7,block=1474

NOTE: starting recovery of thread=1 ckpt=7.1474 group=2 (TEST)NOTE: BWR validation signaled ORA-15096Errors in file /u01/app/grid/diag/asm/+asm/+ASM/trace/+ASM_ora_4035.trc:ORA-15096: lost disk write detectedORA-15042: ASM disk "4" is missing from group number "2"

查看ACD元数据：

修改ACD，加大ckpt的seq为9：

修复ACD元数据

修复ACD元数据：

kfed merge /dev/asm-test-diske aun=4 blkn=0 text=acd.txt

挂载磁盘组

再次尝试mount磁盘组，发现磁盘组挂载正常。

SQL> alter diskgroup test mount force;

Diskgroup altered.

启动数据库

如果在正常环境中，此时会出现数据不一致的情况，当然，如果有归档日志在，那么就可以向本案例一样，完美的解决。

SQL> recover database;Media recovery complete.SQL> alter database open;

数据验证

经验证，数据已经找回。

总结

此类故障是在生产环境中很少遇见，这么多年的Oracle经验，也只遇到几次这个故障。如果真遇到此类问题，不要慌，静下心来，三思而行。

那么，生产环境中我们应该怎么来规避类似的故障呢？

1. 使用Oracle ADG技术搭建容灾环境，此环境千万不能少，既可以做读写分离、也可以容灾、还可以用于误删除恢复，如果经费不够，可以搭建单机版本，目前单机环境X86+10T SSD  不到10W就搞定，这存放的不是数据，是最后的救命稻草。

2. 搭建实时的备份系统。

 往期回顾

• Oracle比特币勒索病毒加密恢复系列一：加密数据文件的恢复解决方案

• 恶意程序清空TAB$(ORA-00600 16703)表恢复系列一：TAB$表清空报错错误汇总

• 重磅福利来袭！！快来查收吧~

• TRUNCATE TABLE恢复系列四：无可奈何，利用ODU还原被TRUNCATE表

• 19c grid asm intermediate故障分享

• Oracle 数据库安装系列一：19C 软件安装和补丁升级

• Oracle Data Guard系列第一讲：STANDBY DATABASE的前世今生

Oracle恢复实录

rescureora.com

欢迎扫码关注

让我知道你在看