前不久某客户的一套3节点rac，由于asm disk分区信息丢失导致无法mount。该环境使用了asmlib，再次证明asmlib是个坑呀。
首先我们来看看kfed读取的结果：
我们可以看到，坏头的信息被清空了。
同时我们将该磁盘的前面10M数据dd备份出来，通过UE进行查看发现前面的32k左右的数据被清空了，如下：
至于为什么数据会被清空，这里还不太清楚。从这里可以看出偏移量在32556，跳过这部分数据然后dd即可进行复制恢复处理，我们这里利用了ODU完成整个数据恢复。
不过比较奇怪的是，CRS磁盘组也损坏掉了，采用类似的方法进行处理发现并不奏效，确实有点怪异。当时没有详细采集信息，所以现在也不太方面继续深入分析了。
不管如何，我们不建议使用ASMLIB，推荐使用udev，实际上Oracle从6.x版本就开始推荐使用udev了。
相对来讲并不是一个复杂的恢复case，跟大家简单分享一下！
首先我们来看看kfed读取的结果：
我们可以看到，坏头的信息被清空了。
同时我们将该磁盘的前面10M数据dd备份出来，通过UE进行查看发现前面的32k左右的数据被清空了，如下：
至于为什么数据会被清空，这里还不太清楚。从这里可以看出偏移量在32556，跳过这部分数据然后dd即可进行复制恢复处理，我们这里利用了ODU完成整个数据恢复。
不过比较奇怪的是，CRS磁盘组也损坏掉了，采用类似的方法进行处理发现并不奏效，确实有点怪异。当时没有详细采集信息，所以现在也不太方面继续深入分析了。
不管如何，我们不建议使用ASMLIB，推荐使用udev，实际上Oracle从6.x版本就开始推荐使用udev了。
相对来讲并不是一个复杂的恢复case，跟大家简单分享一下！
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
