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