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: Online backup: Backup online redologs?

Re: Online backup: Backup online redologs?

From: Spencer <spencerp_at_swbell.net>
Date: Mon, 7 May 2001 00:50:33 -0500
Message-ID: <oHqJ6.192$II4.179017@nnrp2.sbc.net>

i have to chime in here. maybe i missed this important point in your conversation, and at the risk of repeating what has already been said...

the reason that Oracle recommends NOT copying the online redo logs as part of a hot backup procedure is simply put...

the risk that an "old" backup copy of an online redo log will be "restored" over top of a perfectly good online redo log file, which could very well "wipe out" valid redo entries that are needed for complete recovery.

the point is, you should never need to restore a copy of an online redo log prior to a recovery operation.

so, including "backup" copies of online redo log files in a "hot backup set" is of dubious value... since the backup copy of the online redo log file should never be restored, is not just useless, it is downright dangerous.

when the pressure is on to get the database files restored and the database recovered, how are you going to make sure that the junior dba restores ONLY datafiles and does NOT restore the online redo log files ? having the backup copies of the files available only raises the risk that these files will be restored. Yikes!

since the control files and online redo logs are so critical in the recovery of an Oracle database, we protect from data loss using disk mirroring, multiple control files (on separate disk drives) and multiple members (on separate drives) in each logfile group.

the ONLY time that i have found a need for a backup copy of the online redo log files was specifically in setting up an initial "clone" database as a replication target using Quest SharePlex Overdrive. note that this was NOT for recovery of an existing database, but for setting up a new database.

'nuf said.

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:3af0ffa5_at_news.iprimus.com.au...
>
> "Charles Fisher" <Charles.Fisher_at_alcoa.com> wrote in message
> news:Pine.GSO.4.31.0105021450240.3474-100000_at_unknown...
> > On Wed, 2 May 2001, Howard J. Rogers wrote:
> >
> > > > I also shouldn't take hot backups of the redo logs, > but that seems
> > > > to work pretty well, doesn't it?
 

> > > Er, no. We may be at cross purposes here, in which case I haven't a
> > > clue what you are on about. But hot backups of redo logs are
> > > invariably useless for any purpose you care to mention. They are
> > > internally inconsistent, and there is nothing that can make them
> > > consistent.
> >
> > In theory, you are right. However, in practice, you have essentially
> > admitted that you are wrong.
> >
> > The Oracle documentation does indeed claim that you should never take
 hot
> > backups of the online redologs because of the danger of running over the
> > 'end of backup' marker in a log replay.
> >
>
> That's really the least of your worries. If you are doing O/S backups,
 you
> have no control over what bit of the redo log is being copied at what
 time.
> If you happen to be writing to the bit as it is being read, it will be
> useless for subsequent use. Accordingly, if you are not writing to the
 logs
> at all, or if the level of writes is low, and you happen to get lucky, I'm
> sure you'll get away with it. Not exactly a strategy I'd be relying on,
> anyway. And *that's* why Oracle support won't endorse the backing up of
 hot
> redo logs... it's purely a matter of chance whether it works or not.
>
> > However, in my original post, I did a successful 'RECOVER AUTOMATIC
> > DATABASE' on a restore of a hot backup with hot copies of the redologs.
> > You admit in your original reply that the poster might have "gotten
 away"
> > with it, even if it was a "lousy technique." The fact that it worked at
> > all demonstrates that it can work in practice.
> >
>
> That's rather like saying "Gee, I walked across the lanes of a freeway
 with
> a blindfold and didn't get hit once!... this must be a perfectly
 respectable
> way of crossing a road". It isn't.
>
> > As I see it, the 'end of backup' marker has been archived if an "ALTER
> > SYSTEM ARCHIVE LOG CURRENT" has been run (after taking the last
 tablespace
> > out of backup mode, but before using OS utilities to copy). Hopefully,
 the
> > risk of this circumstance is minimal.
> >
>
> Again, I may be wrong, (and now I know you working on 7, I won't press the
> point), but there's a log switch induced by that command, and that
 therefore
> makes the 'current' log just archived INactive -and a hot copy of an
> inactive log is, effectively, a cold copy. No problems of inconsistency,
> therefore.
>
> > > > Either it is the same or it is different; you must choose.
 

> > > I don't have to do anything. My reply is accurate. Both sorts of
 files
> > > will be internally inconsistent. In your terms, that means they both
 have
> > > been introduced to 'the same sort of corruption' (inconsistency should
 be
> > > distinguished from true corruption, but practically they result in the
 same
> > > grief). But one you can fix, and the other you can't.
> >
> > I'm not so sure.
> >
> > As I understand it, redologs are written sequentially. Transactions with
> > SCNs are written in a linear manner to the redologs, then applied to the
> > datafiles.
> >
> > If LGWR were to die for any reason, leaving an incomplete SCN recorded
 in
> > the redologs, then I assume that upon the next instance startup, RECO
 (or
> > whatever process is doing the recovery) is smart enough to recognize the
> > incomplete record in the redologs, check that the datafiles do not
 record
> > that SCN, then essentially do an fseek() in the active redolog thread
 and
> > write over that space.
> >
>
> You are assuming that the thing can be read. If the O/S decided to grab a
> chunk of the current log as it was being written to, the chances of it
 being
> able to interpret the thing at all are slim.
>
> > I would assume that this sort of thing happens quite regularly in
> > "SHUTDOWN ABORT" situations.
> >
> > This may be a rather simplistic view, but the same sort of conditions
> > would exist with a hot copy of the redologs. If a transaction was
> > in-flight, LGWR might have only partially recorded it, in which case it
> > would not have been written to the tablespaces and could be removed with
> > impunity.
> >
>
> As I say, the issue is not whether the contents of the log can be dealt
> with, but whether you can read the contents in the first place.
>
> Anyway: I'll leave you happily backing up hot redo logs and getting away
> with it. This doesn't seem the appropriate forum to debate the merits of
> such an approach.
>
> Regards
> HJR
>
> [Snip]
>
>
>
Received on Mon May 07 2001 - 00:50:33 CDT

Original text of this message

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