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

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;

1) Startup database SQL> startup mount

SQL> recover database SQL> alter database open;

2) If database opens:

- remove parameter _minimum_giga_scn from init.ora and bounce database SQL>  shutdown immediate

SQL> startup

3) 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.