事件起因:
下午他们修了一下午,系统可以进去了,但是数据库在启动到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: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]错误 解决ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]错误](https://i-blog.csdnimg.cn/blog_migrate/334d44e0429c1acd15df208ddd86247a.gif)
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
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
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'
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的这条职场之路,越走越远,祝大家好运。
解决Oracle ORA-00600错误:kcratr_nab_less_than_odr
本文详细记录了解决Oracle数据库出现ORA-00600内部错误代码,具体表现为kcratr_nab_less_than_odr。博主在恢复数据库过程中遇到问题,分析了错误原因,可能是redo日志在传输中丢失,导致数据块丢失。通过重新拷贝redo日志并以RESETLOGS方式打开数据库,最终成功解决问题。博主分享了从错误中学习的经验,并提醒读者重视数据库备份、归档以及保持冷静分析问题的重要性。
3987

被折叠的 条评论
为什么被折叠?



