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

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

数套ASM RAC的恢复案例

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

本文链接地址: 数套ASM RAC的恢复案例

前不久帮助某客户恢复了6套Oracle RAC,均为ASM,而且版本均为10.2.0.4。熬夜好几天,差点吐血了。
这里以其中一套库的恢复进行简单说明,跟大家分享。
其中几套基本上都遇到了如下的ORA-00600 错误:

对于该错误,其实很简单,主要是因为控制文件损坏,通过重建控制文件或者利用备份的控制文件进行restore即可进行mount;甚至于我们利用控制文件快照都可以进行数据库mount;然后接着进行恢复操作。在恢复的过程中还遇到了如下的错误:

上述的ORA-00600错误其实很简单,主要是数据块SCN的问题。这里以其中一套库的恢复进行大致说明,因为在恢复该库的过程中,遇到了一件十分神奇的事情。

由于是ORACLE RAC,因此重建控制文件之后,是需要添加redo logfile的;然而add logfile 发现报上述错误。根据Oracle metalink的一些方法均不能成功,都报上面的错误,确实很怪异。
有些人看上述的错误,可能会认为是设置了OMF的参数,其实这里并不是,我将相关参数全部修改之后,错误依旧。
这里实际上添加logfile时,只写磁盘组名称就行了,不需要写绝对路径。
接着在进行recover后进行open resetlogs打开时,报错ORA-01248,如下:

这个错误还是比较少见,实际上网上那些说法,以及Oracle mos提供的解决方法我发现都不行。
无奈只能先将其offline ,然后再进行恢复。再进行open之前我查询了当前的checkpoint scn如下:

由于open失败,这里我想着是不是这2个文件有问题,又用之前的快照控制文件进行recover一把,然后再次用重建的控制文件起来数据库进行recover,发现神奇的事情出现了:

我们可以看到open 失败了,对于open失败的 情况,我们首先是看alert log,接着10046 trace。

这里我又屏蔽了undo相关的参数。再次尝试发现错误依旧。再次启动,神奇的事情出现了,SCN居然倒退了?

很明显,这个133的scn 回退到了过去2年前了,出现时空穿越了。。。。 当然,open肯定还是报错:

这里先不管为啥连数据文件头的SCN都倒退了(之前被offline的2个文件scn是OK的).  通过10046 trace得到如下内容:

我们这里可以看到,这里报错的SQL读取了file 1 block 218,以及file 40 block 167538。
对于file 1 block 218,我dump 发现没有活动事务;而file 40 block 167538则为undo 块.

同时dump 了这个undo 块,发现确实感觉有些异常,如下所示:

由于所有的文件头SCN 都倒退了,正常open 都报错,只能推进SCN,而且SCN必须要比这个undo block的最大SCN 还要大一些才行,通过在pfile文件中加入参数*._minimum_giga_scn即可。

顺利打开数据库之后,立即将原有的undo 表空间进行drop 并重建。
虽然数据库是打开了,然而其中有2个数据文件之前被我们offline了,而且中间进行了resetlogs操作,因此现在无法进行正常online了。

这里用bbed 将上面2个文件头相关信息修改掉,然后进行recover,可以顺利online文件。

最后建议将数据库expdp 导出并重建。到此告一段落!

Leave a Reply

You must be logged in to post a comment.