生产库的离奇宕机

 

早上听同事说，某省的数据库异常宕机了，数据库在，马上登陆检查，首先看 alert 文件，除了下面一段可疑的记录几乎没有什么线索：

Tue Aug  2 00:26:41 2005
Errors in file /oracle/app/oracle/admin/hemisc/udump/hemisc_ora_17752.trc:
ORA-07445: exception encountered: core dump [kqrfrpo()+288] [SIGSEGV] [unknown code] [0x 400002631F 464000] [] []
Tue Aug  2 00:26:48 2005
Errors in file /oracle/app/oracle/admin/hemisc/bdump/hemisc_pmon_17780.trc:
ORA-30012: undo tablespace 'UNDOTBS2' does not exist or of wrong type
Tue Aug  2 00:26:48 2005
PMON: terminating instance due to error 30012
Instance terminated by PMON, pid = 17780

检查hemisc_pmon_17780.trc跟踪文件，我们发现除了通用文件头以外，只有下面寥寥几行信息，而且仍然在说UNDOTBS2报错。

*** 2005-08-02 00:26:48.714
*** SESSION ID:(1.1) 2005-08-02 00:26:48.713
error 30012 detected in background process
ORA-30012: undo tablespace 'UNDOTBS2' does not exist or of wrong type

于是，检查一下数据库的配置：

SQL> show parameter undo

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      AUTO
undo_retention                       integer     10800
undo_suppress_errors                 boolean     TRUE
undo_tablespace                      string      UNDOTBS1
SQL>        
可以看到，数据库当前使用的是UNDOTBS1，于是推断，是不是有人曾经修改了数据库的undo ts 的设置(比如，是不是曾经使用国UNDOTBS2，但是由于某种原因，如该空间损坏等等，切换到了UNDOTBS1)，于是检查数据库的UNDO空间的状态：

SQL> select tablespace_name from dba_tablespaces where tablespace_name like 'UNDO%';                 

TABLESPACE_NAME
------------------------------
UNDOTBS1

SQL> select * from v$tablespace where name like 'UNDO%';

       TS# NAME                           INC
---------- ------------------------------ ---
         1 UNDOTBS1                       YES

SQL>

这个结果猛地一看，真的让人感到费解，数据库根本就没有“UNDOTBS2”空间，那就奇怪了，难道oracle又出息了？它能够自己预测一个空间名称，还出奇和数据库中已有的空间名称雷同？？ 怪哉！

现在之后两个可能：

1,oracle bug（如果是bug。也是认为操作造成的）

2,人为操作

于是去metalink上检查，果然没有很有说服力的bug，这时，忽然想起这套系统是OS的HA结构，对比一下主机和备机的日志，发现主机宕机后，备机在1分钟之内起来了（大约30多秒），这时候已经基本断定，这是一次人为的故障，虽然没有造成太大的损失，但是我们不得不强调“生产数据库的任何操作都必须是熟知后果的操作”。product不是test！

这个现象不是每次都可以重现的，是在数据库有繁忙业务时（或者job），引起宕机。

但是静止的数据库，可能不会有大的问题。