前几天某客户的一个数据库出现故障，需要我们紧急救援支持。了解了一下环境，着实也吓了一跳，数据量55TB左右。首先我们来看看故障的信息：

 

从前面的日志可以看出，该数据库节点从25号22:57开始报错，开始可能是出现了部分session hung的情况，接着出现了写失败的操作。而其中写失败的是第35个磁盘。

当然，这里仅仅是一个warning，因此我们还不能判断是磁盘是否有问题。

后面我们跟客户了解，当时的现象应该是存储链路出现了异常，导致数据库IO出现异常。这也符合之前的现象描述。

那么我们进一步分析后面客户的操作，看看之前他们都进行了哪些相关的操作？

 

 

我们可以看到，客户进行了正常的alter database open,但是Oracle提示有部分文件需要recover。那么进行recover database操作呢，则提示有部分文件可能来自fuzzy backup.

这是什么意思呢？ 这其实是说这几个文件的检查点比较旧，需要很早之前的日志来进行recover。

由于这是一个非归档的数据库，因此很可能有问题的这几个文件需要日志已经被覆盖。

通过比较scn，我们可以判断这几个文件需要的redo信息已经被覆盖了。这里我要提醒大家的是，不要仅仅只看alert log就轻易下判断。

仅仅看alert log我们可能认为只有几个文件问题。后续我想，如果是仅仅有几个文件有问题，那么我跳过这部分文件进行recover 不就行了吗？ 因为这样可以实现数据的最大程度恢复。

于是我执行了下面的命令：

 

上面这个命令，其实是比较致命的，因为Oracle 会将这里skip的表空间里面的文件全部进行offline drop。

所以这里其实上述的做法是有些欠妥的。

我进一步根据文件的scn和v$log的scn 信息进行比较，发现其实有605个文件可能都需要进行recover；因为全库已经有2000个左右的数据文件。

这里我根据scn进行大致判断然后产生2个脚本进行文件级别的recover，大致获取脚本如下：

 

通过将其他能够进行正常recover的文件进行恢复之后，尝试打开数据库。居然能够正常open数据库。有些人可能已经到此结束了吧，其实并不然。

大家想一下？虽然数据库打开了，我们不能正常recover的605个数据文件中可能还有部分数据文件状态是recover，也就是还不是online的状态。

这种情况之下，业务是无法访问的。实际上我这里查了一下，大概有540个文件状态仍然是recover。因此我们现在还需要想办法怎么去讲这部分文件online。

处理方法其实并不难，比如通过bbed简单修改下数据文件头的checkpoint信息，就可以完成了。但是有540个文件，而且都是ASM环境。

这个修改的工作量可想而已。后面再产生一个脚本，将数据库启动到mount状态，然后将之前状态为recover的文件全部online。

然后进行recover database using backup controlfile操作。接着直接进行alter database open resetlogs。

遗憾的是没有能够直接打开数据库，报了一个如下的错误，该错误很常见，mos有问题也提到，可能跟temp有关系。

 

 

 

 

 

 

 

 

 

这里我这里直接将tempfile 进行drop，然后再重建控制文件，进行recover后，居然直接打开数据库了。

检查alert log,我发现还存在一个如下的错误：

 

 

很明显，上述错误是指smon进程在进行事务恢复时，发现有2个事务无法进行恢复。

看到上述的错误，或许有人会说可能是undo出现损坏，导致无法进行事务恢复。实际上这里并不是，我通过dbv检查发现undo文件都是完好的。

无论怎讲，这里要解决这个问题，相对简单，定位到是什么对象，重建就好。