Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> ora-600, db go splat boom

ora-600, db go splat boom

From: Rachel Carmichael <>
Date: Fri, 07 Sep 2001 06:39:51 -0700
Message-ID: <>

Now that I have your attention:

here's the scenario:
3rd party vendor app (I'm beginning to REALLY hate that phrase and company) database running on

registration database (home-grown) running on

database link from the 8.1.6 db to the 8.0.5 db

programmer changing a report, using the dblink, testing in production (yes, the burning at the stake has been scheduled, you are all invited to watch, bring your own marshmallows)

8.0.5 db starts getting ora-24756 in the alert log 24756, 00000, "transaction does not exist"

// *Cause:   An invalid transaction identifier or context was used or
//           the transaction has completed.
// *Action:  Supply a valid identifier if the transaction has not
//           completed and retry the call.

then ora-600 errors, pmon trace files

8.1.6 db gets the same ora-600 errors in the alert log.

8.0.5 db gets a second, different 600 error, goes splat, BOOM, crash (PMON brought it down)

restarts fine. No data corruption.

Metalink investigation seems to point to a bug in 8.0.4 that isn't fixed until having to do with database links. TAR has been logged and is actually being worked.... and the analyst worked OT on it, even though it isn't a sev 1. There ARE good people in support, I've been lucky to be assigned to one of them

NOW the question:

we were planning on upgrading this db to 8.1.7 in the near future anyway. I'll just do it a bit sooner than originally scheduled.

Any known gotchas? Anything to remember to do? This is a 24x7 database
(aren't they all?)

Plan is:

clone db under 8.0.5
install 8.1.7 and patches
upgrade clone, tracking what I have to do and how long it takes have everyone TEST against the clone to make sure there's nothing in the app that will go boom, especially test that damned link

once the clone is certified as good, upgrade the production database.

Upgrade for production can be done one of two ways, will depend on how long the actual migration/upgrade takes

either: shut it down, the website will be down for x minutes and do it in place

OR: point everyone to the upgraded clone. upgrade production. point everyone back

I really don't want to do the second one, this place has NO documentation, we have pointers to this database all over the place on various machines. I'd hate to miss a tnsnames.ora going in either direction.

Oh yeah -- this is the fun stuff :)


Get your FREE download of MSN Explorer at
Please see the official ORACLE-L FAQ:
Author: Rachel Carmichael

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
To REMOVE yourself from this mailing list, send an E-Mail message
to: (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L

(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Fri Sep 07 2001 - 08:39:51 CDT

Original text of this message