love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

一次TB级ERP(ASM RAC)库的恢复

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

本文链接地址: 一次TB级ERP(ASM RAC)库的恢复

前不见某客户的ERP 库出现故障(Linux x64,10204 rac ams环境). 大概问题是由于一些列操作之后导致磁盘组无法mount,
只能进行数据恢复,针对该case,我们前后投入了8个人力,进行了3天3夜终于成功抢救该数据库。

首先是客户在rac其中一个节点add disk时,发现在另外节点未添加成功,后面又反复折腾add,甚至dd 盘头进行了add。
最为致命的一个动作是强制add disk,其实在该步骤之前这几个disk已经add过一次,且完成了reblance,但是drop disk
却并未成功,最后客户尝试强制添加,如下:

首先利用kfed 读取相关的disk,发现asm的相关元数据基本上都不存在了,因为前面的add disk force其实相当于是吧
diskgroup 重建了一次,其中最为关键的file directory元数据没了。这是非常麻烦的一件事。

在恢复的过程中,我们甚至尝试了Oracle DUL,发现file directory完全丢失的情况下,dul根本无法正常工作。当然,

我们利用老熊的ODU成功的恢复了该库。ODU目前有这样的一个强悍功能,可以进行scan asm disk,然后将所有数据文件

的AU分配信息扫描出并记录到一个文件asm_fileext_meta.odu 中,然后可以自动的将AU进行拼接,也就形成了一个完整

的数据文件,大致的语法如下:

备注:
1.   第一次使用抽取文件的方式进行了恢复,由于数据字典损坏严重,导致数据库open后问题不断(其中还修复了
大量的block,因为部分block是空的,空块是因为部分disk完成了reblance,部分没有,导致抽取的数据字典不完整),
因此我们又重新抽取了一次数据,并重建库导入,前后花费了大量的人力,当然这也是我第一次利用ODU
恢复ERP库,并完美的解决问题。 这里必须赞一个!

2.  关于file directory,可以参考:http://www.killdb.com/2013/01/13/oracle-asm-%e5%89%96%e6%9e%90%e7%b3%bb%e5%88%974-file-directory.html

Leave a Reply

You must be logged in to post a comment.