I think the solution you're looking for is the database flashback
available in 10g; if you are there and your flashback time is large
enough you should be golden.
Otherwise you're probably stuck with doing an incomplete recovery. The
reason for having to do that is Oracle needs to have the entire database
in a consistent state - otherwise you could have some transactions that
are meaningless because the previous transactions did not take place.
Of course you can avoid doing the cold backup before the recovery but
that means you are gambling that the recovery will go right.
I would think that the best way to deal with this kind of thing (other
than 10g's flashback feature) is to have a standby database. You just
stop the updates to the standby while you're application upgrade is
going on, and then it's ready to go if things go wrong during the
upgrade.
Of course if you do happen to have a standby database you could avoid
the cold backup step & just stop the updates during your recovery
attempt.
Kathy
-----Original Message-----
From: Hanes Brad W
[mailto:oracledba-ezmlmshield-x15094559.[Email address protected]
Sent: Friday, October 29, 2004 9:07 AM
To: LazyDBA Discussion
Subject: recovery scenario
we have a rather large database that runs in archive log mode with daily
hot
backups taken. we ran into a situation where an application upgrade
took
place and (long story short) wiped out many of the tables associated
with
that application. according to my research findings, we must run an
incomplete recovery in order to recover to a point in time (time of the
last
hot backup)...this means we have to restore (and uncompress) all of the
datafiles associated with this particular database instance. of course,
this takes quite a bit of time with such a large database. before we do
the
restoration of the datafiles, oracle suggests making a whole, closed
database backup, which defeats the purpose of being available 24x7, and
also
takes quite a bit of time...
it would seem to me that there would be a simpler, more efficient way to
recover from such a scenario with minimal downtime. the lengthy process
we're going through makes me wonder what the benefits are for having a
hot
backup if the database has to be brought down anyways to perform a
"cover-your-butt" cold backup...it also makes me wonder (and this might
just
be an early-morning brainfart), why can't we just recover the
datafile(s)
from the hot backup (which should contain the corrupted tables) and just
recover that particular datafile? I actually did try this yesterday,
but to
no avail. after the datafile restoration and recovery, I was expecting
to
see the populated tables, but did not--why is that? is the "populated
table
data" in the redo logs/archive logs? is it not in the datafiles?? what
is
contained in the hot-backed-up datafiles??
just looking for some clarification and warm and fuzzies....this just
doesn't seem to be a very efficient way to recover a database. thanks
in
advance!
Brad Hanes
SRA International
512-460-4129
--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these
terms:http://www.lazydba.com/legal.html
Oracle LazyDBA home page