ORA-00600

机房环境：

OS：windows 2008

数据库版本：oracle 11g

事件起因：

昨天公司运维说机房的HP服务器磁盘坏了，我当时冷汗一下子就出来了，因为这是测试库，没有备份，没有归档，但是里面可是有1.5T的数据啊，

下午他们修了一下午，系统可以进去了，但是数据库在启动到OPEN的时候报错SYSTEM01数据文件缺失一千多个数据块，由于没有备份和归档，所以这个数据库是挂掉了。

（DBA们一定要做好备份，否则最后全是自己的事情），幸好我们还有一个一周前的冷备库，所以我直接物理迁移，把数据库恢复到一周以前了，恢复的过程非常简单，因为数据库必须的那些文件路径都已存在（如参数文件内的DUMP文件等），我只是把参数文件，密码文件，控制文件，数据文件恢复到指定的目录，然后直接STARTUP，在nomount和mount阶段都是比较顺利的，而到open阶段的时候，则报错了让我闹心的ORA-600ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr]的错误，因为大家都知道，ORA-600是数据库自己内部的BUG，我也是第一次遇到，问了很多人大家都不会，所以只能自己去摸索解决，值得庆幸的是在摸索了一个小时后，我终于把数据库OPEN了，以下就是我恢复的步骤，如果感觉对您有所帮助，那么请支持我一下。

//报错：ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []

//因为ORA-600的错误没有具体提示，所以很多人无从下手，别着急，我们可以先去告警日志去看看，以下是我的告警日志信息：

ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], [

Incident details in: d:/app/administrator/diag/rdbms/ccxe/ccxe/incident/incdir_2570/ccxe_ora_2164_i2570.trc
Aborting crash recovery due to error 600
Errors in file d:/app/administrator/diag/rdbms/ccxe/ccxe/trace/ccxe_ora_2164.trc:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []
Errors in file d:/app/administrator/diag/rdbms/ccxe/ccxe/trace/ccxe_ora_2164.trc:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []
ORA-600 signalled during: alter database open...
Tue May 10 10:13:10 2011
Trace dumping is performing id=[cdmp_20110510101310]
Tue May 10 10:13:11 2011
Sweep [inc][2570]: completed
Sweep [inc2][2570]: completed
Tue May 10 10:29:52 2011
Shutting down instance (immediate)
Shutting down instance: further logons disabled

//我们通过告警日志文件好像也没查到什么有用的信息，别着急，我们还可以再查找对应的TRC文件，我的对应TRC文件则是ccxe_ora_2788_i2164.trc，以下是我的TRC信息

WARNING! Crash recovery of thread 1 seq 1770 is

ending at redo block 779181 but should not have ended before

redo block 779205

//看，有警告了，意思是我在恢复的时候，丢失了redo日志，当时我很纳闷，怎么会丢失redo呢？最后我把这个问题定位在传输redo的时候可能造成数据块的丢失，因为我以前发生过这类事情，所以我重新拷贝redo日志，再次将数据库启动。

Incident 3771 created, dump file: d:/app/administrator/diag/rdbms/ccxe/ccxe/incident/incdir_3771/ccxe_ora_2164_i3771.trc

ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []

*** 2011-05-10 10:47:11.138

Stopping background process MMNL

*** 2011-05-10 10:47:12.139

Stopping background process MMON

*** 2011-05-10 10:47:13.259

ksukia: Starting kill, flags = 1

ksukia: killed 0 out of 0 processes.

*** 2011-05-10 10:47:14.652

*** 2011-05-10 10:47:14.652 4132 krsh.c

ARCH: Archival disabled due to shutdown: 1089

*** 2011-05-10 10:47:15.653

*** 2011-05-10 10:47:15.653 4132 krsh.c

ARCH: Archival disabled due to shutdown: 1089

//重新拷贝redo日志到指定目录，再次启动数据库。

Total System Global Area 6413680640 bytes

Fixed Size 2187728 bytes

Variable Size 754978352 bytes

Database Buffers 5637144576 bytes

Redo Buffers 19369984 bytes

Database mounted.

ORA-00338: log 4 of thread 1 is more recent than control file

ORA-00312: online log 4 thread 1:

'D:/APP/ADMINISTRATOR/ORADATA/CCXE/REDO04.LOG'

//报错果然不一样了，这次报错的意思是我的日志比我的控制文件新，要我恢复控制文件。

SQL> recover database using backup controlfile until cancel; 指定日志文件恢复

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

D:/app/Administrator/oradata/CCXE/redo04.log

ORA-00279: change 128488612 generated at 05/10/2011 11:13:52 needed for thread

ORA-00289: suggestion :

D:/APP/ADMINISTRATOR/FLASH_RECOVERY_AREA/CCXE/ARCHIVELOG/2011_05_10/O1_MF_1_1771_%U_.ARC

ORA-00280: change 128488612 for thread 1 is in sequence #1771

ORA-00278: log file 'D:/app/Administrator/oradata/CCXE/redo04.log' no longer

needed for this recovery

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

D:/app/Administrator/oradata/CCXE/redo05.log

Log applied.

Media recovery complete.

SQL> alter database open; -必须以RESETLOGS方式打开数据库

alter database open

ERROR at line 1:

ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

SQL> alter database open RESETLOGS ;

Database altered.

OK，现在数据库起来了，通过这次出错我总结了几点，希望对大家有帮助

1：数据库不管是不是测试，都尽量备份，否则出问题哭都来不及。

2：数据库尽量归档，这样就可以恢复数据库在任何时刻。

3：出错时不要慌，要仔细查看报错信息，分析报错，根据自己所掌握的知识一步一步解决，当你把问题解决

时，你会发现排错的过程真的是一个非常提升自己的过程。

4：平常一定要有几个在这方面很强的朋友，因为有的时候并不是自己查资料就能查到的，更多的是需要朋友的

经验与帮助。

注：以上就是这次错误的全部过程，过段时间我会把近期所遇到的错误都整理一下，都分享给大家，通过近期的工作我感觉数据库真的是一个非常庞大的系统，每次遇到新错的时候我都会很郁闷的解决，因为我发现我的懂的还是太少了，学习毕竟是一个由点到线，由线到网的过程，一个问题由模糊到清晰，由清晰再模糊，反复来几遍最终都会很明白的。我们要有清晰的理论知识，出错的时候才会找到出题所在，作为一个DBA冷静，清晰的头脑也很重要，通过DBA的这个行业，也是非常锻炼自己的性格，希望大家都可以在DBA的这条职场之路，越走越远，祝大家好运。

ORA-00600

你可能感兴趣的:(ORA-00600)