![982922d13ed5dec472af15a48e8c4f8d.png](https://img-blog.csdnimg.cn/img_convert/982922d13ed5dec472af15a48e8c4f8d.png)
点击上方蓝字关注我们~
![227edf75810780697e0e53981747d2e3.png](https://img-blog.csdnimg.cn/img_convert/227edf75810780697e0e53981747d2e3.png)
我们的文章会在微信公众号“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 trace可以发现,该磁盘组PST在0、2、4号磁盘上。通过kfed也可以验证:
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
offline fg2
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
fg2为primary extent所在的failgroup,此时手动offline,模拟生产环境的服务器关机。
SQL> ALTER DISKGROUP TEST offline disks in failgroup fg2;
Diskgroup altered.
此时gmon日志中,会生成最新的PST信息,如下:
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
更新数据
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
此处更新数据只是为了最后验证数据的有效性。
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
手动破坏4号磁盘
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
这里采用的dd命令,如果在12C中开启afd后,dd命令会自动过滤。
[grid@rescureora1 trace]$ dd if=/dev/zero of=/dev/asm-test-diskg bs=4096 count=1 conv=notrunc
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000306284 s, 13.4 MB/s
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
故障出现
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
磁盘组已经无法mount:
通过gmon trace观察此时的PST分布情况:
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
查看PST中的磁盘状态
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
修改磁盘状态
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
这里将磁盘0和1的状态值修改为127即可。
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
挂载磁盘组
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
PST修复完成,尝试mount磁盘组:
SQL> alter diskgroup test mount force;
alter diskgroup test mount force
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15096: lost disk write detected
ORA-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-15096
Errors in file /u01/app/grid/diag/asm/+asm/+ASM/trace/+ASM_ora_4035.trc:
ORA-15096: lost disk write detected
ORA-15042: ASM disk "4" is missing from group number "2"
查看ACD元数据:
修改ACD,加大ckpt的seq为9:
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
修复ACD元数据
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
修复ACD元数据:
kfed merge /dev/asm-test-diske aun=4 blkn=0 text=acd.txt
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
挂载磁盘组
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
再次尝试mount磁盘组,发现磁盘组挂载正常。
SQL> alter diskgroup test mount force;
Diskgroup altered.
![b0a27d10e95d126eb017fa733cd2a04f.png](https://img-blog.csdnimg.cn/img_convert/b0a27d10e95d126eb017fa733cd2a04f.png)
启动数据库
![a4f9b2565ff66e03f1eb75a4348e7e8b.png](https://img-blog.csdnimg.cn/img_convert/a4f9b2565ff66e03f1eb75a4348e7e8b.png)
如果在正常环境中,此时会出现数据不一致的情况,当然,如果有归档日志在,那么就可以向本案例一样,完美的解决。
SQL> recover database;
Media recovery complete.
SQL> alter database open;
数据验证
经验证,数据已经找回。
此类故障是在生产环境中很少遇见,这么多年的Oracle经验,也只遇到几次这个故障。如果真遇到此类问题,不要慌,静下心来,三思而行。
那么,生产环境中我们应该怎么来规避类似的故障呢?
使用Oracle ADG技术搭建容灾环境,此环境千万不能少,既可以做读写分离、也可以容灾、还可以用于误删除恢复,如果经费不够,可以搭建单机版本,目前单机环境X86+10T SSD 不到10W就搞定,这存放的不是数据,是最后的救命稻草。
搭建实时的备份系统。
![672c7f8151ff6a737c9fc59d271ee0bd.gif](https://img-blog.csdnimg.cn/img_convert/672c7f8151ff6a737c9fc59d271ee0bd.gif)
Oracle比特币勒索病毒加密恢复系列一:加密数据文件的恢复解决方案
恶意程序清空TAB$(ORA-00600 16703)表恢复系列一:TAB$表清空报错错误汇总
重磅福利来袭!!快来查收吧~
TRUNCATE TABLE恢复系列四:无可奈何,利用ODU还原被TRUNCATE表
19c grid asm intermediate故障分享
Oracle 数据库安装系列一:19C 软件安装和补丁升级
Oracle Data Guard系列第一讲:STANDBY DATABASE的前世今生
Oracle恢复实录
rescureora.com
欢迎扫码关注
![78365f7b7882440f300c9f91a581b1c7.png](https://img-blog.csdnimg.cn/img_convert/78365f7b7882440f300c9f91a581b1c7.png)
让我知道你在看
![27c8b7e123fe874de208899b500a0fe4.gif](https://img-blog.csdnimg.cn/img_convert/27c8b7e123fe874de208899b500a0fe4.gif)