Re: PITR from a Cold Backup

"Charles Davis" <cdavis10717_at_comcast.net> wrote in message news:EP6dnWwExL8R2yvdRVn-gg_at_comcast.com...

> 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.

Charles: I wanted to just add to my earlier advice, since I've been thinking about why you were expecting anything other than the advice I gave. I think the clue I missed was that you are thinking about how to perform disaster recovery, and disaster recovery would presumably include the loss of all current control files and all online redo logs, and therefore my advice to only restore the data files would look a bit suspect.

The issue is, however, that there are varying degrees of DR nastiness you could practice.

1. Loss of all data files, but the current control files and online redo logs are safe
2. Loss of all data files and the current control files, but the online redo logs are safe
3. Loss of everything

Scenario 1 was what I was really talking about before: just restore the data files, leaving the existing control files and online redo logs in place. "Recover database" is the command, and complete recovery then takes place.

Scenario 2 will obviously require that you restore all data files. You may also restore a binary backup of your control files. In which case, the command is "recover database using backup controlfile". Oracle can get the last possible SCN out of the existing current redo log because your restored control file still points to the physical location of that log (we hope -you need a new control file backup any time you change the physical layout of your database). It therefore knows to recover to that point and then stop. Then you open resetlogs. It's a complete recovery, because the online redo logs weren't lost, but your database is in a new incarnation, and you therefore have no usable prior backups or archives: an immediate new backup is therefore required for safety.

Scenario 2 is better handled, however with a trace file backup of the control file. You restore all data files. You still have your existing online redo logs. The current log of that set will contain the last possible SCN number. The trace file backup of the control files is a script which contains the paths to all the data files and online logs (and since the trace file is merely a text file, you could edit these paths if you've changed them after creating the trace file). Therefore, your server process is once again able to read the SCNs in all the data files AND in the current redo log. It then knows what SCN to roll the data files forward to. And it creates a new set of control files for you. Your database is completely recovered and remains in its existing incarnation. Prior backups and archives are thus still usable.

Scenario 3 is the big one, of course. But in fact, it's handled in pretty much the same way as scenario 2. Restore all data files and a binary control file, and tell Oracle to 'recover database using backup controlfile until cancel'. When Oracle attempts to apply redo that was in the now-lost current log, it will error out, so just type the word 'cancel', and open resetlogs. That's an incomplete recovery, and you'll have lost whatever transactions were sitting in the former current log. The open resetlogs command re-creates new online logs for you. The database is in a new incarnation, so a new backup is in order. Because it's an incomplete recovery, you will *have* to be in a new incarnation, so the trace file trick of scenario 2, whilst still do-able, offers no real benefits over the binary controlfile backup method.

So, the principle is still: only restore what actually has been lost. In most scenarios, that definitely does mean: do not restore the control files. In *no* scenario do you restore the backed-up redo logs. In the total loss scenario, there is no obvious mechanism to cause that mismatch between SCNs which usually drives the recovery process... but that's what the 'using backup controlfile' command does for you. In the total loss scenario, there is also nothing to indicate to Oracle when recovery should automatically stop... but that's what the 'until cancel' clause does for you.

I hope I haven't confused you, anyway. It was just that I only now realised that you were wanting to rehearse disaster recovery scenarios, and hence my advice about the control files was not really addressing your concerns.

Regards
HJR Received on Thu May 27 2004 - 17:25:05 CDT