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

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

11.2.0.4 ASM RAC 恢复一个例子

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

本文链接地址: 11.2.0.4 ASM RAC 恢复一个例子

这是一个朋友的客户的数据库,数据库出故障之后,无法顺利打开,如下是数据库在open的时候所报的错误:

我们可以看到,通过不完全恢复之后,通过加入隐含参数强制拉库,发现仍然报如下的错误:

据朋友讲,多次尝试之后仍然报上述错误,我建议通过10046 trace发现如下的几个block有问题:

通过bbed 检查发生上述几个block,发现确实存在活动事务。 通过bbed手工提交事务之后,尝试open发现报如下错误:

这个错误其实很简单,是因为需要重建一下控制文件,然后再次尝试open数据库即可。不幸的是,再次open发现报ORA-00600 [2662]错误:

由于他这里的环境是11.2.0.4版本,因此老的推进scn的方式已经不行了,后面我建议通过oradebug 直接修改scn来拉库,如下:

通过上述命令修改之后,再次进行open,发现顺利打开数据库:

虽然数据库能够打开,据朋友反应,很快数据库就会挂掉。从上述日志来看,open之后报错undo 相关错误。这就更容易处理了。通过undo_management参数改成manual即可,然后open数据库,重建undo表空间,如下:

最后打开之后,仍然发现有一些问题,重建index发现都报错错误。如下:

这实际上是存在坏块,通过检查相关对象,发现数据字典表其实存在问题,此时检查发现alert log也存在相关错误,如下:

据我分析,其实完全可以通过bbed修复obj$的index,来完成这个工作。然而朋友不熟,考虑到index结构的复杂性,因此后面直接建议他exp导出重建数据库算了。
我博客中也有相关针对ora-08102错误,修复Index的情况,请参考!类似这样专业的数据恢复,请联系我们云和恩墨!

Leave a Reply

You must be logged in to post a comment.