Re: PITR from a Cold Backup

"Charles Davis" <cdavis10717_at_comcast.net> wrote in message news:EP6dnWwExL8R2yvdRVn-gg_at_comcast.com...
>
> "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> news:40b51e3e$0$1582$afc38c87_at_news.optusnet.com.au...
> >
> > "Charles Davis" <cdavis10717_at_comcast.net> wrote in message
> > news:D5mdneji9-C7YCnd4p2dnA_at_comcast.com...
> > > Hi, all.
> > >
> > > Is it possible to restore an Oracle cold backup, and then apply
archives
> > > created after the cold back to recover the database to a specific
point
> in
> > > time?
> >
> > Of course. The temperature of one's backups does not determine what you
> can
> > do with them. Whether an incomplete recovery is possible or not is only
> > governed by whether the database is in archivelog mode, and whether the
> > archives thus produced are all still safe and sound.
> >
> > > If so, can you please point me to the documented process, the startup
> > > method, recovery clause, etc.
> >
> > The procedure would be *exactly* the same as it would be for performing
an
> > incomplete recovery with a hot backup.
> > Namely:
> >
> > restore all data files (but not the control files or online redo logs)
> > startup mount
> > recover dataabse until <something>
> > alter database open resetlogs.
> >
> > There is nothing at all different about it, hot or cold.
> >
> > Regards
> > HJR
> >
> >
>
> Thank you, HJR.
>
> As I read your reply it seems as though I restore the datafiles but keep
the
> newer control and redos.

You *never* restore control files, unless you've lost them, of course. It's the control files which tell us the point to which the data files should be rolled forward (like the data files, the control file contains the database current SCN. Unlike the data files, the control files are the first things to be read at startup. Therefore the control files can be considered something of a 'master clock' for the database. You don't ever want to trash your master clock by restoring things on top of it unless you've a very good reason).

And you *never*, *ever* restore online redo logs. For the simple reason that they should never be included in your backups in the first place, hot or cold.

> So, the control files have 'knowledge' of the archives created after the
> backup and so will drive the recovery process?

See above. It's the desire to synchronise the data files' SCN with the control files' SCN that actually drives the recovery process. (The online redo logs also have a role to play in instance failure scenarios, since there can be redo from a time after the last SCN in the current online log... the database needs to synchronise actually to that very last piece of redo. But it's mainly the control file's SCN that's the driving force here).

> I was assuming I would also restore the controlfiles and redos, with the
> datafiles, and then just blithely apply archive logs created after the
> backup and up to the present time.

You did a cold backup, right? All cold backups are totally consistent, assuming you shutdown immediate and not abort. Therefore, if you restore the entire cold backup, what need does it have of recovery? None, is the answer (and now I'm beginning to understand why you asked your original question!!). If you restore an entire consistent cold backup (data files+control files+online logs which shouldn't have been backed up in the first place but were anyway!), then no: you cannot induce that database to perform media recovery. If you deliberately create an SCN mismatch, however, by only restoring the data files, then media recovery will follow as day does night.

> > Am I being clear? I am about to attempt a recovery as I've described
using
> a split-mirror backup of a 1.4TB database to prove a DR capability, and I
> thought I understood what I had to do, but your reply was not what I was
> expecting.

Oh. Split mirrors are another issue. What makes you certain that your backup is a cold one in the first place? Do you suspend the database before you split your mirror? If you don't, and you don't shut down either, then you don't actually have a valid backup at all.

If, however, you shutdown, split, startup, backup split, re-silver, then that's fine. Or if you suspend, splt, resume, backup split, re-silver, that's fine too. You will of course inevitably capture images of your online redo logs when you do things this way, so all I can urge you to do is: pretend they don't exist. Never be tempted to restore online logs. It's 100% totally unnecessary, but can also be significantly dangerous if you succumb to temptation, in that it can result in inadvertent data loss.

But the comments above all still stand. Don't restore that which doesn't *need* restoring. And unless you've lost your control files, or lost your online logs, you will therefore never need to restore those two components of the database.

HTH
Regards
HJR Received on Thu May 27 2004 - 16:48:30 CDT