Re: Online backup: Backup online redologs?

"Charles Fisher" <Charles.Fisher_at_alcoa.com> wrote in message news:Pine.GSO.4.31.0105181156360.987-100000_at_unknown...
> On Fri, 18 May 2001, Howard J. Rogers wrote:
>
> > > In a related question, can the dbverify command be used to check the
> > > consistency of a hot backup of a redolog?
 

> > No, because it is only designed to be applied to datafiles (online, or
> > offline, or part of a datafile whether on or offline). The fact that
 there
> > is a 'blocksize' parameter should alert you to this: there is no such
 thing
> > as an Oracle block with the redo logs (as also attested by the fact that
> > log_checkpoint_interval is measured in *O/S* blocks, not Oracle blocks).
> > I'm actually slightly gobsmacked that it worked at all, and full marks
 for
> > perservereing (or however it's spelled) to find a block size that
 appears to
> > do the trick -but the results will nevertheless be utterly meaningless,
 and
> > I wouldn't waste your time further.
>
> Actually, dbv suggested a blocksize of 1024 when I tried to run it. Pardon
> me for running the dbv from Oracle 7; Oracle 8 dbv generates slightly
> different messages but the summaries are the same. I guess that you
> yourself would see this if you hot-copied your redo and ran dbv on it.
>

I guess I would, except for two small things. One, I know it is non-sensical to copy the hot redo log, so I wouldn't have such a beast in my menagerie to start with. And two, I know dbv isn't designed to be run against any form of redo log. So I wouldn't have done that either.

That aside, the versioning of dbv is pretty important, as you've discovered.

> Well, assuming that dbverify won't work, and that I do want hot backups of
> the redologs for controlfile rebuilds, what do you think about this
> method:
>
> 1. alter system archive log current, to start a new redolog and minimize
> the risk of an unplanned log switch,
> 2. hot copy the redolog datafiles with os tools, and rename them to
> something like 'dont-use-redo1.log',
> 3. alter system archive log current again, so the corrupt log that I just
> copied now has an intact archive log.
>
> Since dbverify won't work, there is no way to tell if I will "get away"
> with this without a full restore, which does not make me happy.
>
> Is this the cleanest way to do this dirty thing?
>

In practice what you've done is to backup archives of your redo logs... it doesn't help you any, because however you do this, there remains (by definition) a hot online log that you haven't copied. Your step 3 above has switched into a new current log. To perform a complete restore, you're going to need that new current log (yes, even if it hasn't got any real transactions in it). If you can't supply a readable version of that log at recovery time, then you are going to have to do a standard incomplete recovery.

I'm intrigued by your Step 1 -"minimize the risk of an unplanned log switch". You're still charging at mirages... the issue in all of this is not whether there's a log switch or not per se, but whether the copied files will internally make sense. Dead logs are, er, dead.. so however dumb the o/s is, and however wild the order in which it collects the o/s blocks of which the log is composed, you're pretty well guaranteed that the output will exactly match the input. With a hot log, you can't guarantee that. Unless your o/s knows the precise order in which to collect the o/s blocks, starting with the header block, and re-trying any o/s blocks that are currently being written to, the output will be unreadable.

If a log switch happens mid-copy, that's actually rather a good thing as these things go, because it means the log you are copying has suddenly become dead, and you stand a better chance of getting a clean output file (of course, if there's a switch *into* the file you are trying to copy, you're in deep doo-doo... that which you are trying to copy is being overwritten as you are copying it: another reason why hot copies of redo logs are daft).

So, you are right: this still remains a dirty thing, and what you are still wanting to happen (a single tape that can be restored and bingo! the thing's back in working order) is simply not going to happen (well -here's the qualifier, anyway. You might get lucky, and you might pull it off 95 times out of 100, but *in principle*, it is flawed, and hence can't be recommended as standard practice, or a reliable mechanism. If you have ad hoc needs, then yes, I think you are doing all the right things to maximise your chances. And if this is simply for cloning to create a test system, why not? If this was a backup strategy, though, and if I were your boss, I'd tell you to go back to the drawing-board, because backup strategies must be repeatable, guaranteed, and respect the internal workings of the product being backed up).

Regards
HJR
> --------------------------------------------------------------------------