某政府客户Oracle恢复遭遇ORA-01190 和 ORA-600 [krhpfh_03-1202]

 某客户的Oracle数据库环境,由于硬件故障导致undo损坏,且是非归档环境。我们通过通过dbv检测发现大量数据库文件发现存在大量的数据库坏块,如下所示:

通过分析trace文件,我发现里面有如下信息:

于是使用
_corrupted_rollback_segments= (_SYSSMU4$, _SYSSMU5$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$)

然后再次mount,然后recover一下,成功open数据库,但是查询发现file 5和file 6有问题。显示为missing,经过询问在另外一个路径下找到了文件,然后我进行了rename操作,接着进行recover,发现报错。

我们可以看到,reset logs count 和scn 都不一致,这里我们其实可以bbed直接修改即可。
由于这里是windows 平台,比较麻烦,我就不用bbed了,直接用oracle的10015 event 来推进数据库的SCN。

首先启动到mount状态,执行如下命令:

成功open数据库,由于undo datafile本身损坏了,且又是非归档,故直接重建undo了,搞定。

补充下:在操作过程中发现smon在进程recover时有点问题,故使用了下面的event:

event=’10513 trace name context forever,level 2′ event=’10512 trace name context forever,level 1′ event=’10511 trace name context forever,level 2′ event=’10510 trace name context forever,level 1′

某省公安厅数套Oracle RAC(ASM)恢复案例

前不久帮助某客户恢复了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 导出并重建。到此告一段落!