Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Recovery on a New Machine

Re: Recovery on a New Machine

From: Nancy Wells <nancy_b_wells_at_hotmail.com>
Date: 20 Sep 2002 02:21:19 -0700
Message-ID: <1f14c0b1.0209200121.2d58a5f9@posting.google.com>


Richard,

Thank you very much.

Best Regards,
N. Wells

"Richard Foote" <richard.foote_at_bigpond.com> wrote:
> >
> > I have a cold backup of all the datafiles and the control file taken
> > on Sunday night. I also have a copy of the current control file when
> > the system crashed on Wednessday afternoon. I dont have copies of the
> > online redologs and dont have access to the disk drives.
>
> Hi Nancy
>
> OK. Therefore you can only perform an *incomplete* recovery. Complete
> recovery is impossible as you have lost some redo (eg. at least the current
> redo log and any other redo logs that were not archived).
>
> >
> > > If the answer is no, then an incomplete recovery using your cold backup
> > > datafiles and controlfile is your best option. ... resetlogs.
> >
> > Is the BACKUP CONTROLFILE the same as the cold backup control file?
> > How will it know what archived redo logs have to applied.. (Pardon me
> > if this sounds stupid)
>
> Yes it is.
>
> How does Oracle know which redo logs to apply ? The answer is it doesn't per
> se. It looks at the headers of all the data files and recovers from the
> oldest data file. The redo log associated with this oldest file is hence
> requested first. After applying the log, it then simply keeps requesting the
> 'next' redo log. It doesn't know when to end because the control file it
> usually basis this information on is not current (Oracle knows this because
> you have told it as much with the using backup controlfile clause).
> Therefore it just keeps requesting redo logs until you issue the cancel
> command.
>
> Make sense ?
>
> However, as you can not perform a complete recovery, the issue of which
> control file is use is not so crucial. If the database structure has not
> changed between the time of the failure on your primary database and the
> time you will recover to, then either will do. You basically need a control
> file that will describe the state of the database at the point of time you
> will recover to (after the incomplete recovery).
>
> Firstly, make sure you make a backup of your backup files, just in case
> somethings goes wrong. Then, to recover, do the following:
>
> 1. Restore all the data files and the current controlfiles to the new
> machine (using the same directory structure if possible so you don't have to
> recreate the control file and/or rename the data files)
>
> 2) . Restore the archived log files, again to the same directory structure
> as originally archived to simplify recovery
>
> 3) Mount the database using a copy of the original parameter file (if you
> couldn't restore the control files to the same directory structure, remember
> to change the control_files parameter accordingly)
>
> 4) If you couldn't restore the datafiles to the same directory structure,
> issue the alter database rename datafile commands accordingly
>
> 5) Issue the RECOVER DATABASE command (if you restored the 'current' control
> files, do not use the 'using backup controlfile' clause, if you restored the
> backed up controlfile, then do)
>
> 6) Apply all the requested redo logs. If you couldn't restore the archived
> logs as previously, then specify the new location of the redo logs as
> requested.
>
> 7) Once you're applied the last remaining redo log, enter 'Cancel'. Recovery
> is now complete.
>
> 8) Issue the 'alter database open resetlogs' to open the database.
>
> 9) Shutdown and complete a full backup of the database.
Received on Fri Sep 20 2002 - 04:21:19 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US