Re: Recovery scenario

I had something very similar to this happen once. Turns out the problem was that I had asked the backup team to restore from a specific day, knowing that there was only one oracle backup from that day. However, unknown to me, there was also an OS level backup run that backed up the data files, and it was run much later. And they restored both the early Oracle backup and the later OS backup, which overwrote the Oracle backup. So, check the time stamp on the oracle files.

On Jan 31, 2008 1:51 AM, Niall Litchfield <niall.litchfield_at_gmail.com> wrote:

> I agree with Jeremiah - the only puzzling thing to me is how a backup
> controlfile seems to be aware of the creation time of archives created
> after it was. It is early in the morning for me though. Other than
> that though it's basic incomplete recovery isn't it? UNTIL TIME mean
> stop at this time, UNTIL CHANGE means stop at this scn and UNTIL
> CANCEL means keep going till I tell you otherwise.
>
> On 31/01/2008, Jeremiah Wilton <jeremiah_at_ora-600.net> wrote:
> > Pedro Espinoza wrote:
> > > Ram Raman wrote:
> > >> Why would oracle ask for a file that is from 5am when the backup
> finished
> > at
> > >> 1 30am. Is it the "UNTIL CANCEL" that made the difference?
> > >
> > > Because system01.dbf required redo to bring in consistent with all
> > > other datafiles. One way to avoid this is: switch logfiles immediately
> > > after backuping up datafiles, and then backup those archived redo.
> >
> > I am pretty sure that both assertions above are not right. Ram had the
> > right idea. When you add the UNTIL... clause, the recovery session is
> an
> > incomplete, or point-in-time recovery, and you can open it at any SCN
> after
> > the last datafile finished backup (or backup mode ended if not using
> RMAN).
> > Without the UNTIL clause, it is a complete, or continuous recovery,
> which
> > will ask for logs forever.
> >
> > Switching logs (or more properly, archiving the current log -
> '...archive
> > log current') upon completion of a backup would not do anything to
> change
> > the behavior that Ram observed. Further, failing to archive the current
> log
> > would not cause a recovery to demand additional logs beyond the log in
> which
> > the last tablespace came out of backup mode or last datafile finished
> backup
> > (if RMAN).
> >
> > Regards,
> >
> > Jeremiah Wilton
> > ORA-600 Consulting
> > http://www.ora-600.net
> >
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> >
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l