| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> ora-600, db go splat boom
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 8.0.5.0
registration database (home-grown) running on 8.1.6.0
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 8.0.5.2 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 :)
Rachel
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: carmichr_at_hotmail.com 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: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-LReceived on Fri Sep 07 2001 - 08:39:51 CDT
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
 |
 |