Oracle ORA-00600 [4000] ORA-600 [4000] “trying to get dba of undo segment header block from usn”

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: [email protected]

 

Format: ORA-600 [4000] [a]

VERSIONS:
version 6.0 to 9.2

DESCRIPTION:
This has the potential to be a very serious error.

It means that Oracle has tried to find an undo segment number in the dictionary cache and failed.

ARGUMENTS:
Arg [a] Undo segment number

FUNCTIONALITY:
KERNEL TRANSACTION UNDO

IMPACT:
INSTANCE FAILURE – Instance will not restart STATEMENT FAILURE

SUGGESTIONS:

AsperNote 1371820.8,thiscanbeseenwhenexecutingDMLontablesresiding in tablespaces transported from another database.

It is fixed in 8.1.7.4, 9.0.1.4 and 9.2.0.1 The workaround however is to create more rollback segments in the target database until the highest rollback segment number (select max(US#) from sys.undo$;) is at least as high as in equivalent max(US#) from the source database.

It has also been seen where memory has been corrupted so try shutting down and restarting the instance.

Known Bugs

NB

Bug

Fixed

Description

11.1.0.7.4, 11.2.0.1.2,

OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile

* 9145541

11.1.0.7.4, 11.2.0.1.2, OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile

*

9145541

11.2.0.2, 12.1.0.0

after CREATE CONTROLFILE in 11g

+

10425010

11.2.0.3, 12.1

Stale data blocks may be returned by Exadata FlashCache

12353983

ORA-600 [4000] with XA in RAC

7687856

11.2.0.1

ORA-600 [4000] from DML on transported ASSM tablespace

2917441

11.1.0.6

OERI [4000] during startup

3115733

9.2.0.5, 10.1.0.2

OERI[4000] / index corruption can occur during index coalesce

2959556

9.2.0.5, 10.1.0.2

STARTUP after an ORA-701 fails with OERI[4000]

1371820

8.1.7.4, 9.0.1.4, 9.2.0.1

OERI:4506 / OERI:4000 possible against transported tablespace

+

434596

7.3.4.2, 8.0.3.0

ORA-600[4000] from altering storage of BOOTSTRAP$

Bug 1362499
ORA-600 [4000] after migrating 7.3.4.3 to 8.0.6.1 on HP-UX 32-bit Specific to HP-UX, fixed in one-off patch

Historic info on the Oracle 7.3.x issues re unlimited extents and bootstrap$

In 7.3.4 then due to Bug:434596, this can result from altering the SYS.BOOTSTRAP$ table.

When a SHUTDOWN command follows this, the database will not startup again. Example: Any of following modifications of SYS.BOOTSTRAP$

will cause this error:
ALTER TABLE BOOTSTRAP$ STORAGE (MAXEXTENTS UNLIMITED ); ALTER TABLE BOOTSTRAP$ STORAGE (NEXT 1024);
ALTER TABLE SYS.BOOTSTRAP$ STORAGE (MAXEXTENTS UNLIMITED); ALTER TABLE sys.BOOTSTRAP$ STORAGE (MAXEXTENTS UNLIMITED);

A lock byte is now set on the SYS.BOOTSTRAP$ segment header and following shutdown the database will not start.

A select from bootstrap$ before shutdown will cleanout the lock on
the SYS.BOOTSTRAP$ segment header and prevent the errors from occuring. Example: Issue the following BEFORE shutdown:

sql> select count(*) from sys.bootstrap$;
Get a backup history of the Database/s and the exact sequence of steps performed. Two possible options
a) Go back to backup before the storage clause on BOOTSTRAP$ was changed

b) Oracle Support may be able to patch bootstrap$. See Note:43132.1

Obviously, option a) is always the way to go if at all possible.

Articles:
ALERT about changing MAXEXTENTS to UNLIMITED Note:50380.1

Another cause of an ORA-600 [4000] is that a block scn is ahead of the database scn. In that case the block with the high scn could be printed in the trace file and

In that case the block with the high scn could be printed in the trace file and

Event ADJUST_SCN orparameter_MINIMUM_GIGA_SCNNote:552438.1 canbeusedtobumptheSCN.

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
4000 4000 4000 4000 4000 4000 4000 4000 4000 4000

4000 4000 4000 4000 4000 4000 4000 4000 4000 4000


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *