Re: coping the control file

"Atta ur-Rehman" <atta707_at_my-deja.com> wrote in message news:8rjko0$f07$1_at_nnrp1.deja.com...
> a question is embedded.
>
> regards,
>
> :) ATTA
>
> In article <39dd0d9d_at_news.iprimus.com.au>,
> "Howard J. Rogers" <howardjr_at_www.com> wrote:
> >
> > "Keth Slaton" <kslaton_at_newsguy.com> wrote in message
> > news:mqontssg1s7siqd6dj7k4t322q0opu3vuk_at_4ax.com...
> > > Could there ever be a competent newbe question? Oh well
> > >
> > > My question is this when working with control files I understand
 that
> > > I must use the alter database command to create a human readable
 text
> > > file. But would it be possible to just copy the file from one
> > > directory to another? Oh and would I need to do this durning system
> > > maintenance or could I copy the file at anytime.
> > >
> > > Thanks in advance
> >
> > If the database is up and running, then no, you can't just copy the
 control
> > file -it will be internally inconsistent, and unuseable. That's why
 the
> > command 'alter database backup controlfile
 to 'c:\overthere\control.bkp' was
> > invented -because Oracle is producing the copy, it is guaranteed
 consistent.
> > However, that command can indeed be issued at any time of the day or
 night.
> >
> > If the database is fully shut down, then you can copy it as though it
 were
> > any other file on your disk.
> >
> > But the real issue is this: copying the controlfile is fine for when
 you
> > want to start out mirroring. After that, binary versions of the
 controlfile
> > are a royal pain in the butt to work with. When you come to use an
 old
> > binary copy of the controlfile to recover a database that has lost
 all its
> > originals, you will be forced to open the database with a resetlogs -
 and
> > that means, nasically, that all prior backups and all prior archives
 (if
> > you're taking them) are rendered instantly worthless -they now relate
 to a
> > prior incarnation of the database, and can't be used for the present
> > incarnation (except under extraordinary circumstances).
>
> Just wondering what these 'extraordinary circumstances' could be?
>

You really don't want to go there, plus there's no need if (as usually recommended) you perform a complete closed backup of your newly-incarnated database after doing the resetlogs.

Nevertheless, if the wind is blowing in the right direction, and the moon is in the fourth quarter on an alternate Wednesday, then it is possible to store the new controlfile out of harms way, bring back the old one and all the old datafiles, do a recover until the checkpoint number that represented the point at which you did the resetlogs, then bring back the new version of the controlfile, and perform further recovery to bring the new incarnation back up to date. It's called 'recovery through resetlogs', and its nerve-wracking stuff -and as I say if you can avoid it by the simple expedient of taking a new backup straight after doing a resetlogs, you'd be well advised to do so.

It's described in section 7.3 of the backup and recovery document I have on my web site (page 40) -www.geocities.com/howardjr2000

Regards
HJR
> Resetlogs is,
> > therefore, a VERY expensive option, and a binary image of the
 controlfile
> > will guarantee one.
> >
> > The text script you mention (the 'backup controlfile to trace' trace
 file)
> > is much the preferred method of recovering from total controlfile
 loss,
> > provided you keep it up to date... using it, all required copies of
 the
> > controlfile are regenerated from scratch, with the system forcing the
> > highest SCN found amongst the datafiles into the header of the new
> > controlfiles. Thus, there is no resetlogs, and all prior backups and
> > archives remain entirely useable.
> >
> > Regards
> > HJR
> >
> >
>
> --
>
> getting the meanin' of data...
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Received on Fri Oct 06 2000 - 08:23:47 CDT