If you cannot recover data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.
Parnassusdata Software Database Recovery Team
ERROR:
Format: ORA-600 [4194] [a] [b]
VERSIONS:
versions 6.0 to 10.1
DESCRIPTION:
A mismatch has been detected between Redo records and rollback (Undo) records.
We are validating the Undo record number relating to the change being
applied against the maximum undo record number recorded in the undo block.
This error is reported when the validation fails.
ARGUMENTS:
Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block
FUNCTIONALITY:
Kernel Transaction Undo called from Cache layer
IMPACT:
PROCESS FAILURE
POSSIBLE ROLLBACK SEGMENT CORRUPTION
NB Bug Fixed Description
8240762
10.2.0.5,
11.1.0.7.10,
11.2.0.1
Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600 [4137] /
SMON may spin to recover transaction
3210520 9.2.0.5, 10.1.0.2 OERI[kjccqmg:esm] / OERI[4194] / corruption possible in RAC
+ 792610 8.0.6.0, 8.1.6.0 Rollback segment corruption OERI:4194 can occur if block checking detects a
corrupt block
Historic information:
7.3.3 to 8.1.5
==============
Note:69863.1 ALERT: Apparent data corruptions involving Solaris 2.6,
ISM & DR on Starfire
Check USE_ISM parameter on SUN Solaris E10000 Platforms.
ORA-600 [4194] [a] [b]
Versions: 6.0 - 9.2 Source: ktuc.c
===========================================================================
Meaning:
Undo record number mismatch while adding an undo record to an undo
block. This is done by the application of redo.
---------------------------------------------------------------------------
Argument Description:
a. (ktubhcnt): undo record count - This is the maximum number of undo
records that have ever existed
within this Undo Block. In other
words, it is the High Water Mark for
undo records in that undo block.
This is from the Undo Block.
b. (ktudbrec): redo record number - This is the record number for the
new undo record that is to be added
to the undo block. It should be
one greater than the maximum in the
undo block currently. This is from
the Redo Record.
---------------------------------------------------------------------------
Diagnosis:
This error is raised in kturdb which handles the adding of undo records
by the application of redo.
When we try to apply redo to an undo block (forward changes are made by
the application of redo to a block), we check that the number of undo
records in the undo block +1 matches the record number in the redo
record. Because we are adding a new undo record, we know that the record
number in that undo block must be one greater than the maximum number in
that block.
So for UBA=0x08000592.00a0.0b
0x08000592 is the dba of the undo block.
0x00a0 is the seq# number that is in the block that THIS UNDO IS TO
BE APPLIED TO.
0x0b is the number of undo records in the undo block.
In the header this looks like:
UNDO BLK::
xid: 0x0004.00e.0000017f seq: 0x00a0 cnt: 0x0b ........
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 +1. If this is not the case, we get ORA 600 [4194].
This implies some kind of block corruption in either the redo or the
undo block. Look for other errors that would imply that a block is
corrupted.
Note: If the ORA-4194 follows another ORA-600 AND IF AND ONLY IF
the arguments [a] and [b] are the same, then this MAY be due
to Bug:792610 which can cause undo corruption following a
failed block change.
Note:452620.1 has a procedure to patch this inconsistency when the problem
is produced in the SYSTEM rollback segment
---------------------------------------------------------------------------
Known Bugs: (Those bugs that are fixed after version 7.0.12.0.0.
Bugs must be closed or hold useful information.)
Fixed In. Bug No. Description
---------+------------+----------------------------------------------------
8.0.6/8.1.6 Bug:792610 ORA-600 during redo application to a block may
in turn cause an OERI:4194 on the undo block.
E.g., block checking noticing a corrupt index
block during a multi-row insert.
7.1.5 Bug:239671 Truncate (could possibly happen on other
operations too) on 16k+ block size can cause
the maximum number of undo records in a block
(255) to be exceeded.
Workarounds: Use < 16K blocksize, or avoid
using the TRUNCATE command with the DROP
STORAGE option (which is the default).
ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600
ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600
4194 4194 4194 4194 4194 4194 4194 4194 4194 4194
4194 4194 4194 4194 4194 4194 4194 4194 4194 4194