这是一个网友的数据库,据说是非归档，不知道为啥主机强制重启后就无法打开数据库。首先我们来看下他这里在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打开了数据库，比较顺利。
对于通过非常规手段打开的数据库，我们建议进行导出重建，比较保险一些。到此结束吧！