Database recovery scenario....Help! 2004-10-07 - By Bobak, Mark
So, I was doing some backup and recovery testing, and wound up=20
in the following situation:
Oracle 9.2.0.5 on Solaris 8 3-node RAC cluster, w/ Veritas Cluster
software and VxVM on EMC storage w/ BCVs configured
Now, first thing, we thought we 'd try a basic recovery scenario:
1.) sync BCVs
2.) enter backup mode for all tablespaces
3.) split BCVs
4.) exit backup mode
5.) shutdown all instances
6.) restore from BCVs
7.) start up one instance, recover, roll forward.....
Well, the first problem is that the controlfiles had BCVs!
So, they got backed up and restored w/ the datafiles....bad,=20
but not fatal, at least in this case.
I was forced to do "recover database using backup controlfile until
cancel ".
Ok, fortunately, no controlfile corruption, we dodged that bullet.
Next problem:
This is the big one. Some of the datafiles belonging to undo
tablespaces=20
didn 't have BCVs. So, we did a the BCV backup, but missed some
datafiles,
and then we restored everything we had BCVed, which didn 't include some
of the datafiles.
So, I do recovery, I roll forward, and I try to do an open resetlogs,
and I get:
ERROR at line 1:
ORA-01152 (See ORA-01152.ora-code.com): file 85 was not restored from a sufficiently old backup
ORA-01110 (See ORA-01110.ora-code.com): data file 85: '/dev/vx/rdsk/prerac_undo/inp_vundo01_n1 '
So, at this point, there is no valid, supportable way to recover, right?
I ended up setting "_allow_resetlogs_corruption=3Dtrue ", and that
got the database open.
So, my question is, did I have any other alternatives? I 'm pretty
sure I had no choice other than to set the resetlogs corruption
parameter.
Fortunately, this was a test database, specifically for backup
and recovery testing, so, no great loss.
I 'm just curious if I had any alternatives?
-Mark
--
http://www.freelists.org/webpage/oracle-l
|
|
