Re: File needs media recovery after recovery :(

"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 Received on Thu May 27 2004 - 16:32:02 CDT