前几天我们的一位准客户的其中一套较为重要的数据库出现了故障。我们这里先姑且不去分析原因，来将数据库打开提供业务恢复再说。首先我们来看下一线工程师现场发回的报道：

从上述的错误来看。数据库在open时，其中一个递归SQL语句执行失败，该递归SQL执行失败的原因是出现了ora-01555错误，即大家所熟知的快照过旧；同时日志中也明确提到了需要访问的回滚段编号，即第37号回滚段。

根据我们一般的处理思路，需要进行10046 trace跟踪，确认这里的递归SQL是不是访问了一些存在活动事务的Block。

从10046 跟踪来看，报错的SQL 语句访问了2个block；分别是file 1 block 337和file 157 block 164013. 很明显第一个数据块应该是数据字典的block，而157号文件的这个block应该是undo block，因为这里的obj#=0.

接着我们来看看file 1 block 337 的blockdump情况：

从block dump来看,这是一个Index Block。从ITL的信息来看，这个Index Block没有任何活动事务。同时，根据前面的10046 trace来看，报错的递归SQL访问的obj#=20，换成为16进制为c1 15，然而这个Index block 中并没有这个键值；同时我们dump了下一个index block 找到了对应的键值。

我们可以看出，这个index是一个复合索引，其中col 0的c1 15就是表示20. 该行数据对应的数据块地址是004000f100,转换为10进制是：4194545。

我们回到前面的这个问题，为什么递归SQL访问file block 337 然后接着需要去访问undo block呢？ 而且从10046 trace来看fetch r=0，表明并没有获取到数据。说明问题仍然出在这个block的访问上。

这里我们进一步该block的dump来看，发现其scn如下：

当通过dump控制文件的scn来看，明显要小的多,如下：

我们将上述的database checkpoint进行转换：

很明显数据库的checkpoint 明显要比这个Index Block的scn小的多，也就势必导致数据库在启动的时候需要去访问Undo Block。所以这里经过单次的修改undo$  将对应的37号回滚段标记为offline都无法解决这个问题。这里我们首先尝试清除了file 1 block 377的ITL信息之后，启动数据库发现错误发生了改变，如下：

这个错误就非常明白了，就是block scn的问题。而报错的数据块地址为：4194545，这就是我们前面提到的4000f1这个数块，即file 1 block 241 这个数据块。

看起来这个错误本质上来说，可以直接推进scn解决问题。这里我们通过设置*._minimum_giga_scn参数来解决问题。通过设置了该参数之后，成功打开了数据库。

虽然数据库alert log后续还有一些ora-00600 [4097],ora-08102等错误，但是处理都相对简单了。通过重建undo、重建Index即可解决。