Re: Recovery on a New Machine

Comments Embedded.

"Nancy Wells" <nancy_b_wells_at_hotmail.com> wrote in message news:1f14c0b1.0209190056.3316cba0_at_posting.google.com...
> Hi Richard,
>
> Thank you very much for the reply.
>
> > Can you access any portion of the previous database ? The key portion
here I
> > guess are the online redo logs, or specifically those that were not
> > archived. The current controlfile might prove useful too. Hey, if you
can
> > access all the datafiles we can really be in business.
> >
>
> 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. Startup mount followed
by a
> > RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL. Hit cancel when
> > you've applied your last available redo log and open database with
> > 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.

>
> >
> > Losing all your data and corresponding redo log is not a nice situation
to
> > be in.
> >
> > However if you do have access to all the unarchived redo logs, no
worries,
> > they can be applied and bingo, the database is back (although if you're
> > using the backed up controlfile you still need to open the database with
> > resetlogs).
>
> Are you saying if i had all the online redologs, i could have
> recovered completely?

Yes. If you have a complete backup and all the redo logs since the database was corrupted, then complete recovery would have been possible.

Unfortunately this doesn't appear to be the case.

Good Luck

Richard

>
> Thanks a ton and Best Regards,
> N. Wells
>
> >
> > So a lot depends on what is still accessible in your original database.
> >
> > Good Luck
> >
> > Richard
> >
> > "Nancy Wells" <nancy_b_wells_at_hotmail.com> wrote:
> > > I have a database running in archive log mode and i have taken a cold
> > > backup on sunday night.
> > >
> > > Mon/Tue/Wednesday, database is used. Lot of archive files are
> > > generated...
> > >
> > > Wedneday afternoon , database machine is crashed.
> > >
> > > Only option is to set up a new machine and restore the datbase from
> > > the sunday cold backup:
> > >
> > > What is the procedure to restore on a new machine? Just resotore all
> > > the cold backup data files, control files and init.ora (including Redo
> > > logs?) and start the instance?
> > >
> > > How do i recover the Mon-Wed data from the archive logs? My guess is:
> > > Since i've restored from a cold backup (Sundays), my control file will
> > > also be sundays. Do i need to replace it with a latest copy
> > > (preferably Wednessday before crash). From that point can i recover as
> > > usual...
> > >
> > > Thank you very much for your answers.
> > >
> > > N Wells
Received on Thu Sep 19 2002 - 05:50:04 CDT