Re: File needs media recovery after recovery :(

"Howard J. Rogers" <hjr_at_dizwell.com> schrieb im Newsbeitrag news:40b65e42$0$8984$afc38c87_at_news.optusnet.com.au...
>
> "André Hartmann" <andrehartmann_at_hotmail.com> wrote in message
> news:40b6514d$0$26353$9b4e6d93_at_newsread4.arcor-online.net...
>
>
> > > If you are doing a 'set until', you are doing an INcomplete recovery.
> And
> > in
> > > incomplete recoveries, you must restore database; and recover
database;,
> > not
> > > individual data files.
> > >
> > > What are the things which cause us to need to do incomplete recovery?
> > >
> > > a) User error (delete from important_table;...commit;)
> > > b) Loss of all members of the current redo log
> > > c) A complete recovery can't be completed because of the loss of some
> > > required archive logs
> >
> > The most recent backup is lost and thats why I canot retrieve the
archived
> > logs in that backup. So I am trying to recover to the next-to-last
backup
> > which is available. I have already restored my data file BUGEN.ora but
> rman
> > fails to recover it as you can see because it wants the "lost" archived
> > logs. I would be okay with that if only Oracle stopped telling me "data
> file
> > needs media recovery" when i just recovered it (up to a satisfactory
point
> > of time in the past).
> >
> > what can i do ?
>
> Well, you could try reading my post again.
>
> How can you possibly expect to recover one data file to a time which does
> not match the time all the other data files have gotten to?
>
> Short answer is: you can't. All read-write data files must be synchronised
> to each other, and all to the control files, for a database to be opened
> successfully. And since you can't roll your other data files backwards to
> match where bugen.ora is at, you have no choice but to restore ALL data
> files, and roll them ALL forward to the point where you are currently
trying
> to get your bugen.ora file. Since you are restoring all data files,
> including system, you can only do that when the database is in MOUNT
state,
> and you will have to finish things off by openenin the database with a
> resetlogs command. And every single transaction performed on your database
> after SCN 8575 will be lost.
>
> That is the inevitable expense and nightmare of an incomplete recovery.
It's
> why losing archived redo logs is one of the biggest no-no's a DBA can
> accomplish.
>
> The rman command you need (assuming your database has already been
shutdown
> and re-mounted) would be something like:
>
> run {
> allocate channel ....;
> set until sequence 8575 thread 1;
> restore database;
> recover database;
> sql 'alter database open resetlogs';
> }
>
> I note from another of your posts that this database is 24 x 7... in which
> case, you've got a very expensive exercise on your hands. You might
consider
> for the future multiplexing your archives and multiplexing your rman
> backups, too. Losing archives is not an option.
>
> Regards
> HJR
>
>

Thank you guys,

  not just HJR but everyone who took the time to respond. Learned a lot. We will revise our backup policies and server configurations to avoid this situation in the future.

  In order to handle the current case I have decided to drop the corrupted tablespace, re-create it from scratch and import data from a dump (logical backup created through "exp" 2 days ago.). This worked out fine and allowed us to at least have all other data outside BUGEN.ora to remain up to date. BUGEN.ora lost 2 days but as I have learned from all your contributions that was inevitable because the archived logs got lost with the physical backup.

André
:) Received on Fri May 28 2004 - 08:42:39 CDT