Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: ORA-00704: bootstrap process failure

Re: ORA-00704: bootstrap process failure

From: David Sisk <davesisk_at_ipass.net>
Date: Tue, 13 Jul 1999 22:34:03 -0400
Message-ID: <YxSi3.156$w3.294@news.ipass.net>


Hello:

I've seen this problem before.

Step 1: Take away your manager's DBA privileges, or find a new employer.

Step 2: Fix the problem:

When you set the maxextents on BOOTSTRAP$ to unlimited, it leaves a byte set to indicate that it is locked. The problem is not actually whether the maxextents are limited or unlimited, the problem comes from changing this setting. The database won't open as long as this byte is set to indicate "locked".

Contact Oracle Support and have them look up TARs about the BOOTSTRAP$ problem in 7.3.x. (My apologies, but I don't have the bug number available to me at the moment.) They will have you FTP them the first datafile for your SYSTEM tablespace, they will manually edit this byte in the datafile, then they will place it on their FTP site where you can go GET it.

As an alternative, if you have a full export, you could create a new database and import the whole bloody thing.

In the future, don't change (and don't allow anyone else to change) any storage settings on BOOTSTRAP$ or other data dictionary tables unless instructed to do so by Oracle Support!

Best of luck!

--
David C. Sisk
The Unofficial ORACLE on NT site
http://www.ipass.net/~davesisk/oont.htm

Ingvar Larsson wrote in message <7COi3.290$Gj8.187488768_at_newsa.telia.net>...
> Hi Fellows!
>
>Please, if you think you got any idea about how I can
>solve this I would be more than happy. I know this
>might be a little bit to long to be easy to read but,
>please, give it a chance.
>
>The whole started when Oracle wrote a message about
>it could not extend an index in the SYSTEm tablespace.
>The index belongs to a system table.
>
>The manager tried to set extend to unlimited on the
>SYSTEM tablespace and all indexes and tables in
>that tablespace.
>
>Then he tried to restart Oracle but it did not went down
>sp he killed the all of the Oracle processes and manually
>removed allocated shared memory.
>
>Since then we got the following when we tries to restart from
>svrmgrl:
>
>Oracle7 Server Release 7.3.4.0.0 with the 64-bit option - Production
>PL/SQL Release 2.3.4.0.0 - Production
>
>SVRMGR> connect internal;
>Connected to an idle instance.
>SVRMGR> startup nomount;
>ORACLE instance started.
>Total System Global Area 9070936 bytes
>Fixed Size 50832 bytes
>Variable Size 7860936 bytes
>Database Buffers 1126400 bytes
>Redo Buffers 32768 bytes
>SVRMGR> alter database mount;
>Statement processed.
>SVRMGR> recover database;
>Media recovery complete.
>SVRMGR> alter database open;
>alter database open
>*
>ORA-00704: bootstrap process failure
>ORA-00600: internal error code, arguments: [4000], [5], [], [], [], [], [],
>[]
>
>
>The trace file written by Oracle starts as follows:
>
>Dump file /fs1/oracle/app/oracle/7.3.4/admin/agresso/udump/ora_1629.trc
>Oracle7 Server Release 7.3.4.0.0 with the 64-bit option - Production
>PL/SQL Release 2.3.4.0.0 - Production
>ORACLE_HOME = /fs1/oracle/app/oracle/7.3.4
>System name: OSF1
>Node name: alpha
>Release: V4.0
>Version: 878
>Machine: alpha
>Instance name: agr
>Redo thread mounted by this instance: 0 <none>
>Oracle process number: 6
>Unix process pid: 1629, image: oracleagr
>
>*** SESSION ID:(5.3) 1999.07.13.23.33.09.042
>row cache subordinate object:
>address=f73258 type=9(dc_columns) set=0 parent=f742c8
>status=VALID/INSERT/FIXED/-
>data=
>51530008 45545f4c 00005458 00000000 00000000 00000000 00000000 00000000
>00000303 07d00001 00000000 00000001 00000000 00000000 00000000 00000000
>00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>00000000 00000000 00000000 00000000 00000001 00000000
>*** 1999.07.13.23.33.09.078
>ksedmp: internal or fatal error
>ORA-00600: internal error code, arguments: [4817], [16200280], [], [], [],

>[], [
>], []
>Current SQL information unavailable - no session.
>----- Call Stack Trace -----
>st_dump_frame: no proc entry for 0x1201d8080, 0x120120a68
>Aborting stack tracing...
>calling call entry argument values in hex
>location type point (? means dubious value)
>-------------------- -------- -------------------- ------------------------
-
>---
>st_dump_frame: no proc entry for 0x1201d8080, 0x120120a68
>Aborting stack tracing...
>----- Argument/Register Address Dump -----
>----- End of Call Stack Trace -----
>===================================================
>Files currently opened by this process:
>===================================================
>PROCESS STATE
>-------------
>Process global information:
> process: 836608, call: 0, xact: 0, curses: 0, usrses: 0
> ----------------------------------------
> SO: 836608, type: 1, owner: 0, flag: INIT/-/-/0x00
> (process) Oracle pid=6, calls cur/top: 0/87ce80, flag: (0) -
> int error: 0, call error: 0, sess error: 0
> (latch info) wait_event=0 bits=0
> O/S info: user: oracle, term: ?, ospid: 1629
> OSD pid info: Unix process pid: 1629, image: oracleagr
> ----------------------------------------
> SO: 87ce80, type: 2, owner: 836608, flag: INIT/-/-/0x00
> (call) sess: cur 0, rec 0, usr 0; depth: 0
>END OF PROCESS STATE
>
>
>
>
Received on Tue Jul 13 1999 - 21:34:03 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US