Re: Database recovery/Rollforward

From: Bob Swisshelm <swisshelm_at_lilly.com>
Date: 22 Mar 95 05:52:09 EST
Message-ID: <1995Mar22.055210.4257_at_inet.d48.lilly.com>


In article <sxdjd.232.000F7698_at_orca.alaska.edu> David J. DeWolfe, sxdjd_at_orca.alaska.edu writes:
>The Oracle docs/training material et al address the issue of recovery
 where
>you restore *only* a damaged data file (for instance), and them perform
>complete recovery. Or, restore the damaged file, and perform incomplete
>recovery. This is fine, but take the scenario where your data center
 blows up,
>and you take your offsite database backup, and your offsite backup of
 every
>archived log file created since the backup to some new box somewhere.
 This is
>where we're a little confused. You restore *every* file that makes up
 the
>database, which puts you at the point in time of your last backup, and
>everything is in synch, and recovery is not necessary as far as the
 database
>is concerned. But, you (we) want to rollforward by applying every log
 file
>since the backup. The question is, how do you do it? Again, all the docs
 seem
>to address the issue where the database knows that he is out of synch,
 not the
>scenario where you have a bunch of archive logs you want to apply.

If you do a 'normal' recovery, ORACLE is just going to recover to the last checkpoint recorded in the backed up control file. If you want to use your archived redo logs to roll forward in time, you need to use the 'USING BACKUP CONTROLFILE' clause on the 'RECOVER' command. ORACLE will then continue to apply redo logs until you tell it to stop.

So, the process would go something like:

  1. Recover your data files, control files, online redo logs, and archived redo logs from tape.
  2. startup mount the databaes
  3. SET AUTORECOVERY ON
  4. RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
Hope this helps.

Bob Swisshelm | swisshelm_at_Lilly.com | 317 276 5472 Eli Lilly and Company | Lilly Corporate Center | Indianapolis, IN 46285 Received on Wed Mar 22 1995 - 11:52:09 CET

Original text of this message