机房环境：
OS：windows 2008
数据库版本：oracle 11g
事件起因：
昨天公司运维说机房的HP服务器磁盘坏了，我当时冷汗一下子就出来了，因为这是测试库，没有备份，没有归档，但是里面可是有1.5T的数据啊，
![解决ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]错误](http://www.sinaimg.cn/uc/myshow/blog/misc/gif/E___6692EN00SIGG.gif "解决ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]错误")
下午他们修了一下午，系统可以进去了，但是数据库在启动到OPEN的时候报错SYSTEM01数据文件缺失一千多个数据块，由于没有备份和归档，所以这个数据库是挂掉了。
![解决ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]错误](http://www.sinaimg.cn/uc/myshow/blog/misc/gif/E___6706EN00SIGG.gif "解决ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]错误")
（DBA们一定要做好备份，否则最后全是自己的事情），幸好我们还有一个一周前的冷备库，所以我直接物理迁移，把数据库恢复到一周以前了，恢复的过程非常简单，因为数据库必须的那些文件路径都已存在（如参数文件内的DUMP文件等），我只是把参数文件，密码文件，控制文件，数据文件恢复到指定的目录，然后直接STARTUP，在nomount和mount阶段都是比较顺利的，而到open阶段的时候，则报错了让我闹心的ORA-600ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr]的错误，因为大家都知道，ORA-600是数据库自己内部的BUG，我也是第一次遇到，问了很多人大家都不会，所以只能自己去摸索解决，值得庆幸的是在摸索了一个小时后，我终于把数据库OPEN了，以下就是我恢复的步骤，如果感觉对您有所帮助，那么请支持我一下。
![解决ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]错误](http://www.sinaimg.cn/uc/myshow/blog/misc/gif/E___7392ZH00SIGG.gif "解决ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]错误")
//报错：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], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []
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的这条职场之路，越走越远，祝大家好运。
posted on 2015-03-20 15:08
坏男孩 阅读(1344)
评论(0) 编辑 收藏 所属分类:
ORACLE篇章