Email: service@parnassusdata.com 7 x 24 online support!
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: service@parnassusdata.com
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