Oracle ORA-600[4000] ORA-00600[4000]

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

Applies to:
Oracle Server – Enterprise Edition – Version: 8.1.7.4 to 11.1.0.7
Information in this document applies to any platform.

Purpose

Symptoms

Database fails to start because of ora-600[4000].

Alert.log will show:

Errors in file /oracle/admin/sdwh/udump/sdwh_ora_13186.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [1], [], [], [], [], [], []
Tue Sep 9 14:48:04 2008
Error 704 happened during db open, shutting down database
sdwh_ora_13186.trc shows:
*** 2008-09-09 15:33:26.194
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [4000], [1], [], [], [], [], [], []
Current SQL statement for this session:
select ctime, mtime, stime from obj$ where obj# = :1
..
..
row cache parent object: address=0xc9efb27c cid=3(dc_rollback_segments)
hash=35e74caf typ=5 transaction=(nil) flags=00000001
own=0xc9efb2f0[0xc7c83ba0,0xc7c83ba0] wat=0xc9efb2f8[0xc9efb2f8,0xc9efb2f8] mode=S
status=EMPTY/-/-/-/-/-/-/-/-
data=
00000001 ….
BH (0x0x6ffff4ac) file#: 1 rdba: 0x0040007a (1/122) class 1 ba: 0x0x6ff8a000
set: 17 dbwrid: 0 obj: 18 objn: 18
hash: [74ffdc70,c85d94cc] lru: [6ffffad4,c771aabc]
ckptq: [NULL] fileq: [NULL]
use: [c84043f0,c84043f0] wait: [NULL]
st: XCURRENT md: SHR rsop: 0x(nil) tch: 0

LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [255] RRBA: [0x0.0.0]
Using State Objects
—————————————-
SO: 0xc84043d0, type: 24, owner: 0xc722382c, flag: INIT/-/-/0x00
(buffer) (CR) PR: 0x0xc71d1440 FLG: 0x500400
lock rls: 0x(nil), class bit: 0x(nil)
kcbbfbp: [BH: 0x0x6ffff4ac, LINK: 0x0xc84043f0]
where: kdswh02: kdsgrp, why: 0
buffer tsn: 0 rdba: 0x0040007a (1/122)
scn: 0x0000.15ad85b0 seq: 0x01 flg: 0x06 tail: 0x85b00601
frmt: 0x02 chkval: 0xabfc type: 0x06=trans data
Block header dump: 0x0040007a
Object id on Block? Y
seg/obj: 0x12 csc: 0x00.15ad85ad itc: 1 flg: – typ: 1 – DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0001.027.000056dc 0x0080d065.16f2.14 –U- 1 fsc 0x0000.15ad85b0
Trace file shows _SYSSMU1$ has a TX against obj$, and the scn ofthe block touched by this TX is scn:
0x0000.15ad85b0 –> 363693488 decimal.
The ora-600[4000] could be raised at startup if the above scn is ahead of the database SCN.
Last Review Date
October 3, 2008
Instructions for the Reader
A Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are
included in the document to assist in troubleshooting.
Troubleshooting Details
1) Find database SCN
SQL> startup mount
SQL> select checkpoint_change# from v$database;
2) SQL> select ceil(&decimal_scn_expected/1024/1024/1024) from dual;
3) set parameter _minimum_giga_scn=<result from 2> in the init.ora file.
Using the above trace file example, we found:
SQL> select checkpoint_change# from v$database;
355532971
As suspected the database scn = 355532971 is lower than TX scn=363693488.
SQL> select ceil(&decimal_scn_expected/1024/1024/1024) from dual;
Enter value for decimal_scn_expected: 363693488
old 1: select ceil(&decimal_scn_expected/1024/1024/1024) from dual
new 1: select ceil(363693488/1024/1024/1024) from dual

CEIL(363693488/1024/1024/1024)
——————————
1
1) set parameter _minimum_giga_scn=1 in the init.ora file.
2) open the database
startup mount
recover database
alter database open;
4) Startup database
SQL> startup mount
SQL> recover database
SQL> alter database open;
5) If database opens:
– remove parameter _minimum_giga_scn from init.ora and bounce database
SQL> shutdown immediate
SQL> startup
6) Investigate what could cause the ora-600[4000] , could be because customer forced to open database
using _allow_resetlogs_corruption, and if this is the case we strongly suggest to recreate the database
from scratch taking a full export.

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

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:
As per Note 1371820.8, this can be seen when executing DML on tables residing
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.
If the database will not start contact Oracle Support Services
immediately, providing the alert.log and associated trace files

NB Bug Fixed Description
* 9145541 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,
11.2.0.2, 12.1.0.0
OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile
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

Event ADJUST_SCN or parameter _MINIMUM_GIGA_SCN Note:552438.1 can be used to bump the SCN.

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