admin 管理员组文章数量: 1184232
点击上方蓝字关注我们～
我们的文章会在微信公众号“Oracle恢复实录”和博客网站“rescureora” 同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
今天跟大家分享一个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冗余 oracle_ASM磁盘组ORA15042故障处理案例一：NORMAL磁盘组下失败组离线后ORA15042报错的处理... 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/b/1766105086a3437710.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论