RE: Bug 3798351 Importing a pre-existing table may DROP the table on an error
From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Thu, 24 Jun 2010 11:57:27 -0400
Message-ID: <56C99716B00C4B628E13FAC26A558A25_at_rsiz.com>
I definitely agree with the sympathy idea, even though hanging out on a non-terminal release for so long is sort-of asking for a problem. I just don't ever want to be unsympathetic because I'd like sympathy if I ever lose something. And while I don't want to enter into the debate about whether Oracle could ever be liable in a potential suit, it seems clear to me that this particular incident is WAY off the reservation.
Date: Thu, 24 Jun 2010 11:57:27 -0400
Message-ID: <56C99716B00C4B628E13FAC26A558A25_at_rsiz.com>
I definitely agree with the sympathy idea, even though hanging out on a non-terminal release for so long is sort-of asking for a problem. I just don't ever want to be unsympathetic because I'd like sympathy if I ever lose something. And while I don't want to enter into the debate about whether Oracle could ever be liable in a potential suit, it seems clear to me that this particular incident is WAY off the reservation.
In the meantime I have a few questions having read the thread:
- Why is it stated that the entire database must be recovered? Even if only a physical backup is available getting useful contents point-in-time of the destroyed table should only require system, sysaux, rollbacks and the relevant tablespace containing the table. Several very workable protocols for minimizing the amount that must be restored in order to resurrect an individual table at a particular point in time appear in the archives of this very list, dating back to V6. Much easier, also, if you have a test system available for the partial reload.
- Since the drop was pretty obviously a dictionary action only, if
you haven't trashed anything more yet, it is likely dude can save your butt.
You may need to resurrect just the dictionary from prior to the drop to give
dude the extent addresses and such, but take a look at www.ora600.nl
<http://www.ora600.nl/> or www.ora600.be <http://www.ora600.be/> (or any
other reliable file unloader if you know of one.) I'm pretty sure you can read the primer for free an it will probably tell you what you need to know. Maybe the ship has sailed on minimizing the outage, but have you considered this option? - In the event there is an interlocking bug or some incompatibility preventing application of the patch, going forward until this database can be migrated, the bug is apparently only operative if monitoring is on. If you can't turn monitoring off, probably an even better work-around is switching to loading an alternately named table (perhaps the same name in a different schema, whatever is easiest for you to get right) and then using select * from <alternate> as the source of an insert into the existing table. Does that seem like a reasonable alternative for this (and any other) production databases in the affected release range rather than "Just because of this bug 9.2.0.5 and 9.2.0.6 must be prohibited IMHO." ?
All this I mean as considered dialog and please do not interpret any of what I have written as a flame of any sort.
Good luck on the recovery,
mwf
<snip>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Jun 24 2010 - 10:57:27 CDT