某政府客户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′

发表评论

电子邮件地址不会被公开。 必填项已用*标注