Re: Online backup: Backup online redologs?

"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 Thu May 03 2001 - 01:49:48 CDT