mysql redo ubdo log_Oracle ORA-600 [4137] ORA-00600 [4137]”XID in Undo and Redo Does Not Match”

If you cannot recover 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

Format: ORA-600 [4137]

VERSIONS:

versions 7.0 to 10.1

DESCRIPTION:

While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.

This would indicate a corrupted rollback segment.

FUNCTIONALITY:

Kernel Transaction Undo Recovery

IMPACT:

POSSIBLE PHYSICAL CORRUPTION in Rollback segments

SUGGESTIONS:

Signalled during rollback (also rollback for consistent read). The consistency check that compares the transaction id of the transaction being rolled back against the transaction id in undo block being applied is failing.

A possible cause is a lost write to the undo segment.

The main approach is to identify the file containing the bad undo segment block and treat it as if the file is corrupt. Consult the trace file for this information.

If in archivelog mode, restore the file & roll forward.

If in Noarchivelog mode, restore from a cold backup taken before the error was reported.

Alternatively, you can look at dba_rollback_segs data dictionary view.

If the status column that describes what state the rollback segment is currently in is “needs recovery” then lookup the following article for posible solution.

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

671491 8.1.6.0 Rollback Segment corruption possible if RBS has > 32767 extents

ORA-600 [4137] []

Versions: 7.x – 10.x Source: ktur.c

===========================================================================

Meaning:

While backing out an undo record ktuko finds that the transaction

id (txid) in the header of the undo block doesn’t match the

txid in the transaction state object.

—————————————————————————

Argument Description:

No arguments are returned.

—————————————————————————

Diagnosis:

This is a similar kind of error to <4147>, and basically indicates some kind of corruption with the UNDO block.4147>

The main approach is to identify the file containing the bad RBS block and treat the problem as if this file is corrupt. E.g., if in archivelog mode, restore and roll forward.

At the end of the day, this usually comes down to a lost write to the RBS so it is a corruption. The redo stream should be ok.

In the trace file, the transaction ids that do not match are dumped together with the undo block. In 9i and 10G there is also a redo dump for the block. The redo dump shows the file number.

If there is no redo dump, you can use the uba of the undo block and determine which file to restore and roll forward. See .

Search for “buffer tsn” (Oracle8) or “buffer dba” (Oracle7) in the

trace file and find the UNDO block containing the bad transaction ID.

This is the file/block that needs to be recovered.

Here is the code that shows you two transaction IDs and which

is which.

10G:

if (!KXIDEQ(xid, &ubh->ktubhxid)) /* make sure the txid matches */

{

ksdwrf(“XID passed in =”);

KXIDDMP(xid);

ksdwrf(“\nXID from Undo block =”);

KXIDDMP(&ubh->ktubhxid);

ksdwrf(“\n”);

/* dump useg header diagnostics */

KTUR_DIAG_DUMP(&udes->ktusdbds);

/* dump undo block diagnostics */

KTUR_DIAG_DUMP(ubdes);

ksesic0(OERI(4137));

}

9i:

if (!KXIDEQ(xid, &ubh->ktubhxid)) /* make sure the txid matches */

{

ksdwrf(“XID passed in =”);

KXIDDMP(xid);

ksdwrf(“\nXID from Undo block =”);

KXIDDMP(&ubh->ktubhxid);

ksdwrf(“\n”);

KCLDLCK(ubdes->kcbdsafn, ubdes->kcbdsrdba, ubdes->kcbdscls);

kcradx(ubdes->kcbdsafn, KTSNINV, ubdes->kcbdsrdba, 0, 0, 3, (char *)0);

ksesic0(OERI(4137));

}

7.3 – 8.1.7

if (!KXIDEQ(xid, &ubh->ktubhxid)) /* make sure the txid matches */

{

ksdwrf(“XID passed in =”);

KXIDDMP(xid);

ksdwrf(“\nXID from Undo block = “);

KXIDDMP(&ubh->ktubhxid);

ksdwrf(“\n”);

ksesic0(OERI(4137));

}

Before 7.3:

The transaction IDs dumped in the file are in this order:

Expected txid

undo txid

if (!KXIDEQ(xid, &ubh->ktubhxid)) /* make sure the txid matches */

{

KXIDDMP(xid);

KXIDDMP(&ubh->ktubhxid);

ksesic0(OERI(4137));

}

Note: It is unlikely that we will be able to ‘repair/trace’ the corrupt

undo block. With this scenario we typically have two options:

o Assuming the redo is good, we can restore the database file

o Assuming the redo is good, we can restore the database file

and roll forward.

o As a last resort, use undocumented parameter (_offline_rollback_segment or

_corrupted_rollback_segment) and rebuild the database.

—————————————————————————

Articles:

Note:106638.1 Handling Rollback Segment Corruptions in Oracle7.3/8

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

4137 4137 4137 4137 4137 4137 4137 4137 4137 4137

4137 4137 4137 4137 4137 4137 4137 4137 4137 4137