Re: Backup Oracle ? Online Redo Log.

Thanks for your answer !

I've read the file (.PDF) which explain backup and recovery but I not sure understanding why the online redolog files should never be backuped in a hot backup.

For example :
If I have a HOT BACKUP of :

• the whole database at 03h00 am
• the control files,archived logs and online redo logs at 10h00 am , 12h00, 04:00 pm. Imagine that my server burned at the end of the evening ( 05h00 ). Which is the most recent version of my database that can I restore ?

If I restore all datafiles saved at 03h00 am and all control files , redo log files saved at 04:00pm,
Why it is not possible replay all the archived redo log saved between 03h00am and 04h00pm ?

if not, can you tell me what is the best backup strategy for this case of damaged ?

Thanks.

Christian.

"Howard J. Rogers" <dba_at_hjrdba.com> a écrit dans le message news: 3c3d744b$0$1586$afc38c87_at_news.optusnet.com.au...
> You cannot, ever, in a million years, backup an online redo log. It can't
> be done, and you'll risk data loss by attempting it (I've seen a junior
DBA
> restore everything from a backup set, including a hot-copied online log,
and
> as a result over-write a perfectly functioning current redo log with a
pile
> of poo).
>
> Rogers' first rule of hot backups is simply this: You cannot ever hot
backup
> any part of an Oracle database without the end result being internally
> inconsistent. That goes for online redo logs as well as datafiles or
> control files.
>
> Rogers' second rule of hot backups is that internally inconsistent files
are
> not a problem provided Oracle's supplied a mechanism to get them
internally
> consistent. The application of redo makes an internally inconsistent data
> file consistent. But for control files and redo logs, there is no such
> mechanism (you can't apply redo to either).
>
> Now, for control files, Oracle thoughtfully provided the 'alter database
> backup controlfile to...' command, which uses its own special mechanism to
> generate either a trace file (and there's no worries about a text file
being
> inconsistent) or a guaranteed consistent binary image of the control file.
>
> But no such provision was made for taking a hot backup of the current redo
> log.
>
> Therefore, combine rules one and two with the lack of an alternative
> mechanism and the conclusion is inescapable: hot backups of the current
redo
> log will be internally inconsistent, utterly unusable, and no mechanism
> exists to rectify the situation.... therefore, hot backups of them are a
> complete waste of time.
>
> You can of course perform a cold backup of said redo log, by the simple
> expedient of shutting the database down.... at which point, you don't
> actually have a current redo log any more, just a bunch of dead o/s files.
> There is no problem copying such a closed redo log at all... but it will
be
> out of date the second you re-open the database.
>
> Visit my site, read the backup and recovery documents there, especially
the
> large one under the 'books' link, and you'll see that unless you are
running
> in noarchivelog, there is zero usefulness in backing up the current log at
> all. What's more, doing so risks inadvertent (and unnecessary) loss of
data
> when it comes time to recovery. Without doubt, the current redo log is
the
> Achilles' heel of the entire Oracle architecture -which is why they
invented
> redo log mirroring (or, more accurately) multiplexing so that total loss
of
> the current log should be a very rare occurrence -making attempted backups
> of it even more of a waste of time than they otherwise would be.
>
> Regards
> HJR
> --
> ----------------------------------------------
> Resources for Oracle: http://www.hjrdba.com
> ===============================
>
>
> "Christian MERCK" <cm_at_sdv.fr> wrote in message
> news:3c3d4dda$0$14589$4d4eb98e_at_read.news.fr.uu.net...
> > Hi,
> >
> > It is useful to backup regularly the online redo log ?
> > If yes, how should I do it ? Just an OS copy ?
> >
> > Thanks in advance.
> >
> > Christian.
> >
> >
>
>
Received on Thu Jan 10 2002 - 08:19:46 CST