某客户的数据库出现崩溃，无法正常启动，经过我的远程紧急救援恢复之后，恢复正常，如下是简单的处理过程，供参考！

在open数据库时，发现无法打开，报错如下：

对于上述错误，其实是比较常见的，大致上可以理解为Oracle在open 时需要进行一致性读的处理，却发现回滚段内容已经被覆盖，进而报错ora-01555，导致无法open。我们也可以发现，报错的SQL预计是Oracle 递归SQL，这是数据库在open时必须执行的SQL，很明显，该SQL无法执行成功，那么也就导致数据库无法正常打开。

处理思路很简单，首先我们要做的事情是通过10046 trace跟踪确认数据库在执行该SQL时访问了那些block，进而报错的？

通过oracle 10046 trace得到如下的内容：

根据我们常见的处理思路，将上述访问的block中的事务状态改成8000之后，发现仍然报错。我们仔细来对比下block中的scn与报错的scn信息，发现了其中的关系，如下：

将上述的scn bas值转换为10 进制后为：489416426，我们再来查询下数据库文件头的scn：

我们不难发现，报错的block中的scn比数据文件头的scn要大，其次也比前面报错的的scn：1d2be1e6 （转换后为 489415142）要大一些。这说明什么？

当数据库处于running的情况之下，Oracle 不知道下一个时间点事务什么时间结束，因此也不知道下一个时间点的scn是多少，所以其对应的scn 往往要比当前的大一些。当数据库crash后，加上undo损坏，那么很容易出现这样的情况。

所以，我们这要做的事情，很简单，将上述scn 修改得比报错的scn小一些（或者等于），则可以解决该错误。

修改之后，再次启动数据库，发现报错发生了变化，查看此时的alert log，发现信息如下：

很明显，这是scn的问题，要处理也很简单，通过推进scn即可解决掉。通过推进scn之后，发现打开数据库时，还是报错了，但是错误再一次发生了改变：

这次过程处理起来就很简单了，通过屏蔽undo就可以很容易解决掉。其次在后续的恢复过程中，还遇到了如下的一些错误：

这部分错误处理起来都相对简单的多。【4097】也是回滚段的问题，在处理undo时，可以一并处理之。我博客之前就写了该错误的处理案例，这里不再累述。这种恢复场景，最后打开数据库后一般还会有如下的错误：

最后这个错误处理起来十分简单，通过重建index即可解决上述错误，对于大量的 日志，建议直接grep，然后重建相关index即可。

最后通过mos的脚本来check 数据字典是否存在异常，这样就可以确保数据库起码可以正常运行。如下是检测结果：

我们可以发现，至少通过Oracle mos的脚本检查之后，没有数据字典有问题。

对于这样的复杂数据恢复，建议联系 云和恩墨 获取专业技术支持！