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: URGENT: ORA-01554 upon startup

Re: URGENT: ORA-01554 upon startup

From: Anton Buijs <aammbuijs_at_xs4all.nl>
Date: Tue, 18 Mar 2003 21:31:04 +0100
Message-ID: <3e77821b$0$49111$e4fe514c@news.xs4all.nl>


Just a few ideas.

Have you tried to startup the database with next init.ora values to eliminate any possible activity initiated by the db itself: job_queue_processes=0
aq_tm_processes=0
_system_trig_enabled=false

It's a users process that dies because it writes to udump dir. It dies due to a ORA-604 (error at recursive level). A background process would write its trace file to bdump dir.
But what process is running as a user process during database open? I don't know.
Could it be something looping? Maybe a system (logon) trigger? Should not be possible because db is still opening but it's a strange situation so disable system triggers with the hidden init.ora.

Are all rollback segments that exists included in the init.ora parameter rollback_segments?
If running MTS, disable MTS by making comment of the mts parameters Keep transactions=10000 but reduce processes and/or sessions (if sessions is not set, it is derived from processes).
Is Java loaded in the database? Disableing system triggers should not start Java so that might help too.

I hope that once the database has opened succesfully all init.ora changes can be reversed and the next open will be succesfull as usual.

NetComrade <netcomrade_at_netscape.net> schreef in berichtnieuws ab810584.0303180839.30c9d2a4_at_posting.google.com...
| the original values were
| transactions integer 1820
| transactions_per_rollback_segment integer 5
|
| the new values were
|
| transactions 10000
| transactions_per_rollback_segment 40
|
| I've also tried playing around with these.
|
| The trace file
| /u31/app/oracle/admin/BASE/udump/base_ora_15807.trc
|
| contains nothing but the already mentioned errors.
|
| Oracle support wasn't able to recover the database for us.
| They tried to bring it up with
| _corrupted_rollback_segments= (<segment_list>)
| but that didn't help
| they offerred to come on site and recover the data manually, starting
| at $10K, but that wasn't worth our time. We brought up the data in a
| separate instance with 20 hours of data lost.
| This instance is still left for my amusement. If anybody has any
| suggestions, I'll be more than happy to try them out. (we still would
| like this data back)
|
Received on Tue Mar 18 2003 - 14:31:04 CST

Original text of this message

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