RE: Bug 3798351 Importing a pre-existing table may DROP the table on an error
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <niall.litchfield@xxxxxxxxx>, <dedba@xxxxxxxxxx>
- Date: Thu, 24 Jun 2010 11:57:27 -0400
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:
1) 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.
2) 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?
3) 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>
Other related posts:
