培训班一个学生模拟非归档数据恢复，始终无法打开数据库，我在自己的vm 将其打包的文件进行了恢复，如下是完整的恢复和分析过程，供大家参考！

++++ 编辑pfile并创建相关目录

++++mount启动数据库

+++++ rename datafile & logfile

由于他这里redo有问题，所以只能当redo全丢失来进行处理了。这是为什么rename redo 无法成功的原因。

对于ORA-16433错误，可以通过重建controlfile来解决。

++++++ recreate controlfile

 

++++RECOVER

尝试使用隐含参数，以及屏蔽回滚段，发现错误依旧。对于报错，通常的思路是跟踪，去识别Oracle
为什么会在这个地方报错，下面我们在open resetlogs之前打开10046 event的跟踪：

下面分析10046 trace是重点。通常我们的思路是直接vi 编辑定位到trace的最后，会看到如下的信息：

从10046的跟踪来看，我们发现该SQL访问了如下的几个block：

很明显，前面2个block是system的，后面2个file 3 的block是undo的block。  其中block 208是undo段头block。

我的直观感觉是既然访问这2个block有问题，肯定是有事务，何不直接bbed修改一下呢？ 下面进行了尝试：

注意通过看blockdump，我们知道最后一行记录的lock byte为2. 这里我因此进行了修改（实际上这个事务状态是U，是不需要修改的，这一步骤是错误的思路）

下面先修改block 321：

下面修改block 225：

修改完成之后，尝试，发现仍然报错，如下：

其中还遇到了让我觉得比较怪异的事情是，如果通过bbed修改undo$.status，强制将回滚段修改offline状态的话，那么会遇到如下的问题：

最后再回过头来分析，发现其实犯了一个致命的错误。alert log的ora-01555报错SQL其实和我们10046 最后看到的sql并不是同一个，

换句话讲，直接分析10046 trace的最后部分，是错误的，我们应该找ora-01555报错的这个SQL。

由于10046 trace内容比较多，我们直接切换到最后去查看分析，这样是有问题的。 于是尝试换个思路：

搜索报错的SQLID：3nkd3g3ju5ph1，然后定位到parse ID，然后进行过滤：

大家注意看最后4行，通过过滤我们可以发现其实还有一个file 1 block 20804 也被递归SQL访问了，因此我们之前多次尝试都报错，
是因为直接vi 查看10046 trace的最后部分，没有发现而已，这是非常隐蔽的。

检查发现20804这个block 确实存在一个事务，如下：

修改的同时，我们还需要修改锁定行的lock byte位置，如果找到这一行呢？ 很简单，我们通过dump block，然后直接
查看lock：2就行了，定位到是如下的行：

下面我们讲该行的lock type修改为00即可，这样block的校验不再报错。

 

避免ora-016433错误，我再次重建了controlfile，最后顺利打开了该数据库，如下：

虽然是一个测试库，但是恢复过程还是有意思，也发现了自己之前分析10046 trace的一个致命问题，通常是直接vi 查看trace的最后位置去看，这真是致命的，我想这一点，很多人都是这样，希望大家能有所启发！