前几天同事反馈说某客户的一套数据库出现异常，负载极高，服务器几乎无法操作，只能强行关闭服务器电源来重启数据库；悲剧的是重启服务器之后，数据库无法启动了。

首先我们来看看启动数据库报什么错误：

从上述的错误来看，mount之后，open数据库时报错ORA-00601，而且这是SMON进程抛出的错误；可见这是smon进程在进行事务恢复时抛出的错误，最后的结果就是smon强行终止了实例。这就是为什么同事反馈，只要执行alter database open命令，sqlplus 窗口就报错ORA-03113. 如下是对于trace文件的call stack信息：

我们继续看后面的几个ORA-错误，我们都知道，对于这种一连串的错误，需要从下往上看，即ORA-00601错误是关键，是起因，然后再导致了ORA-27303,ORA-27302 等等错误。

从错误的基本解释来看，基本上判断是存在锁冲突，数据库都没有open，怎么会有锁呢？所以我们不难看出，这应该是操作系统数据库实例的内存没有清理干净。

果然，我ipcs -a查看看到有几个之前启动过的实例还分配着内存呢，同时也还有一些ora-进程存在。通过ps -ef|grep ora|grep -v grep|awk ‘{print $2}’|xargs kill-9 杀掉进程之后，再ipcrm -m 清除即可。

接着尝试启动数据库，手工进行recover database发现又报其他的错误：

这个错误还是比较少见的。最后的这个ORA-00600 [kcoapl_blkchk] 我也是第一次遇到，不过结合前后日志来看，很明显这是数据库在通过redo进行数据块应用时出现了异常，而有异常的数据块则是file 1 block 164301;也就是我们的system 文件。

其次我们也可以看出，该数据块所涉及的对象是data object# 3，也就是我们常说的bootstrap 核心对象，但是这是一个Index。

如果我们再看的仔细一点，可以发现这个块的问题是出在了事务层，因为有ora-10561错误产生。

既然如此，那么我们首先来dbv 检查一下数据库的system文件，看看是否有物理损坏：

通过dbv的结果来看，system 文件本身是没有物理损坏的。如果不是物理损坏，那么结合前面的错误信息来看，我们可以判断这个文件的这个块应该是逻辑损坏。这里我们应该可以通过rman 进一步进行检查确认。

为了尽快启动数据库，这里我们先通过如下的方式来尝试进行恢复：

很顺利的打开了数据库，这也说明目前数据库的问题并不是很严重，只是有问题的数据块并不多，否则上述的命令是不会起到什么作用的。

这里我简单补充一点，对于allow  n corruption的操作，在Oracle 9i 和10g 版本中，仅仅支持1个corrupt block；而在11gR2版本开始，则可以支持多个，最多可达10个 corrupt block。

打开数据库之后，我检查了数据库alert log发现，有一些其他的错误，如下所示：

单纯的看到上述错误，我开始以为是不是因为我们前面执行了allow 1 corruption的恢复，所以导致sql执行报错。

针对该错误，我查询了一下Oracle metalink，其中的文档ORA-600 [25012] “Relative to Absolute File Number Conversion Error” (文档 ID 100073.1) 提到该错误则表示可能是存在物理损坏。其中[0] 表现表空间编号，[852]表示相对文件号。

但是根据实际的情况来看，这似乎不对，因为这个数据库目前仅有200多个数据文件，不太可能出现文件号大于800的情况。其次dbv 检查system文件确实是没有物理损坏。

这里我们姑且不管mos文档是不是对的，就只看这个错误来看，是调用的监控脚本运行出错，监控脚本的本意是通过查询数据库dba_segments试图来获取数据库的大小。

那么我们进一步看看dba_segments的访问是否会涉及到我们前面提到的data object# 3呢？ 通过vi trace文件，搜索Plan_table关键字即可看到报错SQL语句的执行计划，我发现并没有涉及到data object# 3的对象。

由此可见，这个数据库除了我们前面提到的data object# 3,还有其他的对象可能也存在逻辑不一致的错误；因此建议进行全库级别的一致性检查，如有必要，建议重建一下数据库。

对于这个问题产生的根本原因，我一直在思考，到底是什么原因呢？最开始我怀疑可能有如下几种可能性原因：

1、强制重启主机，导致主机cache 丢失，最终导致Oracle redo或datafile 存在write lost；

2、数据库的system文件之前就存在不一致的情况

3、Oracle bug

由于客户这套Oracle 9208数据库使用的是裸设备，因此Oracle 对于文件的读写按理说是不会应该操作系统cache的，因此不存在第一种情况的说法。所以我认为要么是数据库之前可能就有一定问题要么就是命中了Oracle的某个bug（具体是什么bug，没有去深入排查）。

这里我也提醒一下，对于Oracle 9i这种老库，尤其是非归档的情况，不建议强制重启，可能出现一些异常。