系统crash掉导致ORA-00600的处理

国庆期间重新整理了机房，一堆机器移行换位，估计oracle没有关闭就直接拔电源了。到今天开发人员报告一台测试的db连不上，于是处理开始。

[@more@]

因为这台机器的数据库是开机自动启动的，直接登陆上去查看listener状态，正常，然后登陆到数据库中查看数据库状态：
SQL> select open_mode from v$database;

OPEN_MODE
----------
MOUNTED

奇怪，于是先把数据库关闭，然后重新启动，报错如下：
SQL> startup
ORACLE instance started.

Total System Global Area 1375731712 bytes
Fixed Size 1260780 bytes
Variable Size 603980564 bytes
Database Buffers 754974720 bytes
Redo Buffers 15515648 bytes
Database mounted.
ORA-00600: internal error code, arguments: [kcratr1_lastbwr], [], [], [], [], [], [], []

查看ALERT日志，发现
Errors in file /opt/oracle/admin/billdb/udump/billdb_ora_7186.trc:
ORA-00600: internal error code, arguments: [kcratr1_lastbwr], [], [], [], [], [], [], []
ORA-600 signalled during: ALTER DATABASE OPEN...

打开上面提到的trace文件
*** SERVICE NAME:() 2007-10-11 10:08:49.493
*** SESSION ID:(989.3) 2007-10-11 10:08:49.493
Successfully allocated 2 recovery slaves
Using 543 overflow buffers per recovery slave
Thread 1 checkpoint: logseq 67179, block 2, scn 2132065607
cache-low rba: logseq 67179, block 5453
on-disk rba: logseq 67179, block 5828, scn 2132066974
Starting CRASH recovery for thread 1 sequence 67180 block 1
Thread 1 current log 5
Scanning log 5 thread 1 sequence 67179
Scanning log 6 thread 1 sequence 67178
Cannot find online redo log for thread 1 sequence 67180
start recovery at logseq 67179, block 5453, scn 0
----- Redo read statistics for thread 1 -----
Read rate (ASYNC): 252Kb in 0.03s => 8.22 Mb/sec
Total physical reads: 252Kb
Longest record: 9Kb, moves: 0/341 (0%)
Change moves: 1/24 (4%), moved: 0Mb
Longest LWN: 35Kb, moves: 0/110 (0%), moved: 0Mb
Last redo scn: 0x0000.7f14c2af (2132066991)
----------------------------------------------
******** WRITE VERIFICATION FAILED ********
File 15 Block 89 (rdba 0x3c00059)
BWR version: 0x0000.7f14c25e.01 flg: 0x04
Disk version: 0x0000.7f14c12d.01 flag: 0x04
*** 2007-10-11 10:08:49.541
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcratr1_lastbwr], [], [], [], [], [], [], []
Current SQL statement for this session:
ALTER DATABASE OPEN

上面提示说貌似找不到67180的日志了，去日志目录看看明明在的，于是跑到metalink上去，查到如下结果：
Changes
There was a disk problem that caused the database to crash.
Cause
Oracle is unable to perform instance recover but it works when is invoked manually.
Solution
Mount the database and issue a recover statement

SQL> startup mount;

SQL> recover database;

SQL> alter database open

于是照搬上面的步骤，手工恢复后问题解决。
但搞不明白为啥oracle自己不能恢复，手工恢复就可以呢？下一步还是查查硬件错误吧。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25016/viewspace-975790/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25016/viewspace-975790/