故障处理 ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [1348],[657132], [657133],

一、接客户保障，数据库主机重启后无法连接

二、检查数据库状态是mount。

SQL> select open_mode from v$database;

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

三、进行OPEN，出现了ORA-00600错误[kcratr_nab_less_than_odr]

SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [1348],[657132], [657133], [], [], [], [], [], [], []
四、检查数据库的对应的aler文件和trc文件，recovery失败。应该是客户重启电脑，导致LGWR写REDO LOG失败，重启后做恢复无法从REDO LOG里面获取到恢复的信息。（(cache-low)redo block 657132 but should not have ended before
redo block 657133（on-disk））

trc文件部分内容如下

*** 2018-12-03 17:17:11.315
Successfully allocated 15 recovery slaves
Using 10 overflow buffers per recovery slave
Thread 1 checkpoint: logseq 1348, block 2, scn 14828824655476
  cache-low rba: logseq 1348, block 656162
    on-disk rba: logseq 1348, block 657133, scn 14828824780377
  start recovery at logseq 1348, block 656162, scn 0

*** 2018-12-03 17:17:11.537
Started writing zeroblks thread 1 seq 1348 blocks 657132-657139

*** 2018-12-03 17:17:11.605
Completed writing zeroblks thread 1 seq 1348
==== Redo read statistics for thread 1 ====
Total physical reads (from disk and memory): 4096Kb
-- Redo read_disk statistics --
Read rate (ASYNC): 485Kb in 0.19s => 2.49 Mb/sec
Longest record: 2Kb, moves: 0/1779 (0%)
Change moves: 54/647 (8%), moved: 0Mb
Longest LWN: 33Kb, moves: 0/196 (0%), moved: 0Mb
Last redo scn: 0x0d7c.9ad55e57 (14828824780375)
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 262144
Longest hash chain = 1
Average hash chain = 115/115 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 1921/3170 = 0.6
----------------------------------------------
WARNING! Crash recovery of thread 1 seq 1348 is
ending at redo block 657132 but should not have ended before
redo block 657133
Incident 1032199 created, dump file: F:\APP\ADMINISTRATOR\diag\rdbms\hydee\hydee\incident\incdir_1032199\hydee_ora_1344_i1032199.trc
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [1348], [657132], [657133], [], [], [], [], [], [], []

ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [1348], [657132], [657133], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [1348], [657132], [657133], [], [], [], [], [], [], []

四、先做一次所有数据文件和控制文件以及日志文件的物理冷备份。尝试下是否可以进行恢复，1348的归档文件是不存在，无法进行恢复，尝试一下用1347的归档文件，也无法恢复。

SQL>  recover database using backup controlfile until cancel ;
ORA-00279: 更改 14828824800376 (在 12/03/2018 16:07:20 生成) 对于线程 1
是必需的
ORA-00289: 建议:
F:\APP\ADMINISTRATOR\ARCHIVELOG\HYDEE\ARC0000001348_0954755508.0001
ORA-00280: 更改 14828824800376 (用于线程 1) 在序列 #1348 中

指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00308: 无法打开归档日志
'F:\APP\ADMINISTRATOR\ARCHIVELOG\HYDEE\ARC0000001348_0954755508.0001'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

--尝试1347

指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
F:\app\Administrator\archivelog\hydee\ARC0000001347_0954755508.0001
ORA-00310: 归档日志包含序列 1347; 要求序列 1348
ORA-00334: 归档日志:
'F:\APP\ADMINISTRATOR\ARCHIVELOG\HYDEE\ARC0000001347_0954755508.0001'

SQL> exit

四、既然从常规的恢复手段中无法恢复，那就开始进行重建控制文件，打开数据库。

C:\Users\Administrator>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on 星期一 12月 3 19:16:19 2018

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> oradebug setmypid
已处理的语句
SQL> Alter session set tracefile_identifier='controlfilerecreate' ;

会话已更改。

SQL> Alter database backup controlfile to trace noresetlogs;

数据库已更改。

SQL>  oradebug tracefile_name ;
F:\APP\ADMINISTRATOR\diag\rdbms\hydee\hydee\trace\hydee_ora_3920_controlfilerecreate.trc
SQL>
 

sqlplus / as sysdba

shutdown immediate;

startup nomount;

@F:\APP\ADMINISTRATOR\diag\rdbms\hydee\hydee\trace\hydee_ora_3920_controlfilerecreate.trc

 

五、重新启动数据库，并做一次逻辑备份。

六、如果不用这种方法操作，其实也可以用隐含参数_allow_resetlogs_corruption强制启动数据库，然后再进行导出和导入确保业务数据正常。