Email: service@parnassusdata.com 7 x 24 online support!

    You are here

Step by step to resolve ORA-600 4194 4193 4197 on database crash

Step by step to resolve ORA-600 4194 4193 4197 on database crash

If you cannot recover the data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.

Parnassusdata Software Database Recovery Team

Service Hotline:  +86 13764045638 E-mail: service@parnassusdata.com

 

The following error is occurring in the alert.log right before the database crashes.  ORA-00600: internal error code, arguments: [4194], [#], [#], [], [], [], [], []

This error indicates that a mismatch has been detected between redo records and rollback (undo) records.  ARGUMENTS:

 

Arg [a] - Maximum Undo record number in Undo block  Arg [b] - Undo record number from Redo block

 

Since we are adding a new undo record to our undo block, we would expect that the new record number is equal to the maximum record number in the undo block plus one. Before  Oracle can add a new undo record to the undo block it validates that this is correct. If this validation fails, then an ORA-600 [4194] will be triggered.

 

CHANGES

 

This issue generally occurs when there is a power outage or hardware failure that initially crashes the database. On startup, the database does the normal roll forward (redo) and then  rollback (undo), this is where the error is generated on the rollback.

 

CAUSE

 

This also can be cause by the following defect

Bug 8240762 Abstract: Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600 [4137] after SHRINK  Details:

Undo corruption may be caused after a shrink and the same undo block may be used  for two different transactions causing several internal errors like:

ORA-600 [4193] / ORA-600 [4194] for new transactions  ORA-600 [4137] for a transaction rollback

 

SOLUTION

 

Best practice to create a new undo tablespace.  This method includes segment check.

 

Create pfile from spfile to edit

>create pfile from spfile;

 

1.Shutdown the instance
2.set the following parameters in the pfile  undo_management = manual

event = '10513 trace name context forever, level 2'

 

3.>startup restrict pfile=<initsid.ora>
4.>select tablespace_name, status, segment_name from dba_rollback_segs where status != 'OFFLINE';  This is critical - we are looking for all undo segments to be offline - System will always be online.
 

If any are 'PARTLY AVAILABLE' or 'NEEDS RECOVERY' - Please open an issue with Oracle Support or update the current SR. There are many options from this moment and Oracle  Support Analyst can offer different solutions for the bad undo segments.

 

If all offline then continue to the next step

 

5.Create new undo tablespace - example

>create undo tablespace <new undo tablespace> datafile <datafile> size 2000M;

 

6.Drop old undo tablespace

>drop tablespace <old undo tablespace> including contents and datafiles;

7.>shutdown immediate;  8 >startup mount;

 

9 modify the pfile with the new undo tablespace name

>alter system set undo_tablespace = '<new tablespace>' scope=pfile;

 

10.>shutdown immediate;
 
11.>startup;