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

这是一个网友的数据库,据说是非归档,不知道为啥主机强制重启后就无法打开数据库。首先我们来看下他这里在open的时候所报的错误:

对于这个错误而言,我想大家都非常熟悉了,不就是可以直接推进SCN 就可以解决吗?根据我们常规的恢复方式,那么肯定是 alter session set events ‘10015 trace name adjust_scn level 13697’;
最开始也让该网友才有这样的方式进行尝试,得到的回复是数据库是11.2.0.4。这就比较悲剧了,因为从oracle 11.2.0.3版本开始Oracle已经不再支持通过这种event或者隐含参数的方式来推进数据库SCN了。 唯一的方式就是oradebug 修改数据库scn。
据说这是windows环境,那么修改数据库SCN就相对麻烦一些。如下是我自己做的一个windows 虚拟机修改SCN的例子,供参考:

我想大家已经知道,其实windows x64环境而言,修改SCN也很简单,前面4个byte是bas scn,后面4个byte是wrap scn;因此这里如果我们要推进scn,那么直接修改wrap 即可。直接修改wrap scn值需要后移动4个offset,然后直接修改即可。
不幸的是,我告诉网文这种博客中有类似的修复例子,他修改之后仍然无法打开数据库,错误仍然一样。比较麻烦了,对于比较难的问题对于我而言是比较有吸引力的。
首先让对方做个10046 trace 跟踪,得到如下类似信息:

从上面的信息来看,目前数据库在open时在执行CURSOR# 92370008时处于wait状态,然后失败。
从上述信息不难看出,这里涉及到几个block:file 1 block 225;file 1 block 539;file 3 block 128.
很明显file 1 block 225 是undo$。而file 3也是undo文件。
让对方提供dump file 1 block 128信息,发现确实是存在活动事务,如下所示:

很明显,上面第0x1a 事务是活动事务,而涉及到的块地址为:0x0040021b
同时如下是file 3 block 128 的dump信息:

从dump 来看,file 3 block 128 并没有问题。那么也就是问题可能出在前面file 1 block 128和file 1 block 539 这2个block上。
进一步dump file 1 block 539,发现如下:

很明显,这是一个undo block,而且是系统回滚段。而最前面的2662 错误的rdba地址,其实是比较容易让人产生错误判断的:

因此,我们可以断定,数据库无法open,那么跟undo有关系,而且是system 回滚段。
接着让对同时设置如下event并同时设置_corrupted_rollback_segments参数。:alter system set event=’10513 trace name context forever,level 2 : 10512 trace name context forever,level 1: 10511 trace name context forever,level 2: 10510 trace name context forever,level 1′ scope=spfile;
这里需要说明一下,windows环境比较麻烦,可以借用dd fow windows版本进行copy block,然后过滤得到回滚段信息,并全部进行屏蔽。
尽管把我的杀手锏都告诉了对方,得到的答复是仍然无法打开数据库,报错ORA-01555,如下所示:

对于这个错误,我深有体会,本质上是因为open时访问的数据块需要利用undo而出现的错误。换句话讲,该block存在活动事务。
再次建议通过10046 event跟踪定位到了有问题的数据块,如下所示:

从上面的信息来看,file 1 block 665 和 block 705 存在异常。 建议对方进行bbed修改,但是。。。。。。

通过对上述2个block 的dump 内容如下:

好人做到底,就虚拟机帮忙修改一下把,如下是手工提交事务修改block的过程,供参考

修改完毕后,然后通过如下类似的dd命令替换掉system文件中的问题block:
dd if=blk_665.665 of=SYSTEM01.DBF seek=665 bs=8192 count=1 conv=notrunc
dd if=blk_705.705 of=SYSTEM01.DBF seek=705 bs=8192 count=1 conv=notrunc
据说替换掉block后,最后recover 一把,就直接open打开了数据库,比较顺利。
对于通过非常规手段打开的数据库,我们建议进行导出重建,比较保险一些。到此结束吧!

    分享到:
18180207355
加Q咨询