Oracle non-archive recovery with ora-00600 [kcratr_nab_less_than_odr]

I encountered the following problems:

1. The mount control file is abnormal. Replace the file and use pfile to mount the file.
2. open reported the following error:

Fri Jul 04 20:03:23 2014
Alter database open
Beginning crash recovery of 1 threads
Parallel recovery started with 15 processes
Started redo scan
Completed redo scan
Read 229 KB redo, 0 data blocks need recovery
Errors in file d: \ app \ administrator \ diag \ rdbms \ yunhaoorcl \ trace \ yunhaoorcl_ora_3416.trc (incident = 160589 ):
ORA-00600: Internal error code, parameter: [kcratr_nab_less_than_odr], [1], [11783], [8], [1181], [], [], [], [], [], [], [], []
Incident details in: d: \ app \ administrator \ diag \ rdbms \ yunhaoorcl \ incident \ incdir_160589 \ yunhaoorcl_ora_3416_i160589.trc
Aborting crash recovery due to error 600
Errors in file d: \ app \ administrator \ diag \ rdbms \ yunhaoorcl \ trace \ yunhaoorcl_ora_3416.trc:
ORA-00600: Internal error code, parameter: [kcratr_nab_less_than_odr], [1], [11783], [8], [1181], [], [], [], [], [], [], [], []
Errors in file d: \ app \ administrator \ diag \ rdbms \ yunhaoorcl \ trace \ yunhaoorcl_ora_3416.trc:
ORA-00600: Internal error code, parameter: [kcratr_nab_less_than_odr], [1], [11783], [8], [1181], [], [], [], [], [], [], [], []
ORA-600 signalled during: alter database open...
Fri Jul 04 20:03:25 2014
Trace dumping is refreshing Ming id = [cdmp_20140704200325]
Fri Jul 04 20:03:27 2014
Sweep [inc] [160589]: completed
Sweep [inc2] [160589]: completed

This is rare. It may be due to a problem during instance recovery. Try to manually recover the database:

SQL> recover database;
Media recovery is completed.
SQL> archive log list;
Database log mode non-archive mode
Disable automatic archiving
Archiving end point USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 11781
Current log sequence 11783
SQL> alter database open;
Alter database open
*
Row 3 has an error:
ORA-00600: Internal error code, parameter: [kcratr_nab_less_than_odr], [1], [11783], [8],
[1181], [], [], [], [], [], [], []
Manual recover cannot be found. Check that alert log reports an error and check the corresponding trace as follows:

* ** 20:03:23. 792
Successfully allocated 15 recovery slaves
Using 10 overflow buffers per recovery slave
Thread 1 checkpoint: logseq 11782, block 2, scn 230294634
Cache-low rba: logseq 11782, block 52177
On-disk rba: logseq 11783, block 1181, scn 230308328
Start recovery at logseq 11782, block 52177, scn 0
 
* ** 20:03:24. 058
Started writing zeroblks thread 1 seq 11783 blocks 8-15
 
* ** 20:03:24. 058
Completed writing zeroblks thread 1 seq 11783
=== Redo read statistics for thread 1 ====
Total physical reads (from disk and memory): 4322Kb
-- Redo read_disk statistics --
Read rate (ASYNC): 229Kb in 0.11 s => 2.04 Mb/sec
Longest record: 3Kb, moves: 0/269 (0%)
Change moves: 6/101 (5%), moved: 0 Mb
Longest LWN: 5Kb, moves: 0/115 (0%), moved: 0 Mb
Last redo scn: 0x0000. 0dba37ae (230307758)
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 65536
Longest hash chain = 0
Average hash chain = 0/0 = 0.0
Max compares per lookup = 0
Avg compares per lookup = 0/0 = 0.0
----------------------------------------------
WARNING! Crash recovery of thread 1 seq 11783 is
Ending at redo block 8 but shocould not have ended before
Redo block 1181.
Let's take a closer look at the instance recovery information and get the following information:
Thread 1 checkpoint: logseq 11782, block 2, scn 230294634
Cache-low rba: logseq 11782, block 52177
On-disk rba: logseq 11783, block 1181, scn 230308328
Start recovery at logseq 11782, block 52177, scn 0
Thread checkpoint: logseq 11782, block 2, scn 230294634
Low cache rba: logseq 11782, block 52177
On disk rba: logseq 11783, block 1181, scn 230308328
We can see that the starting point of instance recovery is low cache rba (in fact, oracle will compare the thread check points and low cache rba, and select the larger ones as the start point of instance recovery ).
Finally, let's take a closer look at this error:
ORA-00600: Internal error code, parameter: [kcratr_nab_less_than_odr], [1], [11783], [8], [1181], [], [], [], [], [], [], [], []
Kcratr_nab_less_than_odr: Make a bold guess to compare a value.
[1]: the thread number.
[11783]: the logseq value of on disk rba
[8]: unknown
[1181]: block number of on disk rba
Finally searched MOS, Oracle gives the explanation as follows, about this ora-00600 error:
This caused a lost Write into the Online RedoLogs and so Instance Recovery is not possible and raising the ORA-600.
In general, that is, the loss of online log write causes instance recovery to fail to recover to the specified point, and then throw this ora-00600 error.
For on disk rba, this value must be reached by oracle instance recovery. If it cannot be restored to this value, an exception will occur, similar to the problem here.
Now that you understand this, it is easy to recover. First, rebuild the controlfile:

SQL> CREATE CONTROLFILE REUSE DATABASE "YUNHAOOR" NORESETLOGS NOARCHIVELOG
2 MAXLOGFILES 16
3 MAXLOGMEMBERS 3
4 MAXDATAFILES 100
5 MAXINSTANCES 8
6 MAXLOGHISTORY 1168
7. LOGFILE
8 GROUP 1 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ REDO01.LOG 'size 50 m blocksize 512,
9 GROUP 2 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ REDO02.LOG 'size 50 m blocksize 512,
10 GROUP 3 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ REDO03.LOG 'size 50 m blocksize 512
11 -- STANDBY LOGFILE
12 DATAFILE
13 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ SYSTEM01.DBF ',
14 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ SYSAUX01.DBF ',
15 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ UNDOTBS01.DBF ',
16 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ USERS01.DBF ',
17 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ FENG_SPACE.DBF ',
18 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ SYSTEM02.DBF ',
19 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ SYSTEM03.DBF ',
20 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ USERS2 ',
21 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ SYSAUX1 ',
22 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ system1'
23 character set ZHS16GBK
24;
 
The control file has been created.
 
SQL> recover database;
Media recovery is completed.
Finally, I opened the database and found that an error was reported again. But fortunately, this is an error that the DBA knows how to solve, as shown below:

SQL> alter database open;
Alter database open
*
Row 3 has an error:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [],
[], [], [], []
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [],
[], [], [], []
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [],
[], [], [], []
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [],
[], [], [], []
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [],
[], [], [], []
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [],
[], [], [], []
Process ID 6760
Session ID: 534 Serial Number: 1
 
SQL>

Actually, viewing the alert log also saw the ora-00600 [4193] error. This method is the same.

(Incident = 171742 ):
ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d: \ app \ administrator \ diag \ rdbms \ yunhaoorcl \ incident \ incdir_171742 \ yunhaoorcl_smon_3884_i1742.trc
No Resource Manager plan active
Errors in file d: \ app \ administrator \ diag \ rdbms \ yunhaoorcl \ trace \ yunhaoorcl_ora_6760.trc (incident = 171790 ):
ORA-00600: Internal error code, parameter: [4194], [], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d: \ app \ administrator \ diag \ rdbms \ yunhaoorcl \ incident \ incdir_171790 \ yunhaoorcl_ora_6760_i1790.trc
Fri Jul 04 20:12:34 2014
Trace dumping is refreshing Ming id = [cdmp_20140704201234]
Trace dumping is refreshing Ming id = [cdmp_20140704201235]
Doing block recovery for file 3 block 217
Resuming block recovery (PMON) for file 3 block 217
Block recovery from logseq 11784, block 63 to scn 230347995
Recovery of Online Redo Log: Thread 1 Group 3 Seq 11784 Reading mem 0
Mem #0: D: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ REDO03.LOG
Block recovery stopped at EOT rba 11784.67.16
Block recovery completed at rba 11784.67.16, scn 0.230347992
Doing block recovery for file 3 block 144
Resuming block recovery (PMON) for file 3 block 144
Block recovery from logseq 11784, block 63 to scn 230347989
Recovery of Online Redo Log: Thread 1 Group 3 Seq 11784 Reading mem 0
Mem #0: D: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ REDO03.LOG
Block recovery completed at rba 11784.65.16, scn 0.230347991
Errors in file d: \ app \ administrator \ diag \ rdbms \ yunhaoorcl \ trace \ yunhaoorcl_smon_3884.trc:
ORA-01595: error freeing extent (2) of rollback segment (2 ))
ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], []

For ora-00600 4193/4194 errors, specify undo_management = maual through pfile, and then enable the database to recreate undo, as shown below:

SQL> create undo tablespace undotbs2 datafile 'd: \ APP \ ADMINISTRATOR \ ORADATA \ YUNHAOORCL \ undotbs2_01.dbf
2 size 4096 m;
 
The tablespace has been created.
 
SQL> shutdown immediate
The database has been closed.
The database has been detached.
The ORACLE routine has been disabled.
SQL> startup mount pfile = 'd: \ 1. ora'
The ORACLE routine has been started.
 
Total System Global Area 9620525056 bytes
Fixed Size 2183872 bytes
Variable Size 4395633984 bytes
Database Buffers 5200936960 bytes
Redo Buffers 21770240 bytes
The database has been loaded.
SQL> alter database open;
 
The database has been changed.
 
SQL> show parameter undo
 
NAME TYPE VALUE
-----------------------------------------------------------------------------
Undo_management string AUTO
Undo_retention integer 900
Undo_tablespace string UNDOTBS2
SQL> drop tablespace undotbs1 including contents and datafiles;
 
The tablespace has been deleted.
Note: After recreating the controlfile, remember to add the tempfile. Do not add mines to people!
ORA-600 [kcratr_nab_less_than_odr] during Instance Recovery after Database Crash (Document ID 1299564.1)
Alter database open fails with ORA-00600 kcratr_nab_less_than_odr (Document ID 1296264.1)