早上听同事说,某省的数据库异常宕机了,数据库在,马上登陆检查,首先看 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),引起宕机。
但是静止的数据库,可能不会有大的问题。