Re: quick hot backup question...

"Jim Kennedy" <kennedy-family_at_attbi.com> wrote in message news:YaPn8.112226$af7.60838_at_rwcrnsc53...
> Howard,
> Think offsite storage. This way I can take the tapes off site each day
and
> if a fire happens later that day then I have everything and nothing in the
> redo (except of course after the switch).

Well, that's the point of course. Switching does nothing to give you assurance that you have 'everything', because by its very nature a hot backup is a backup of a continuum, an on-going process of raising new transactions. Snapshot it anyway you like, but the continuum, er, continues immediately after the log switch, so any efforts to make one snapshot equate to everything are essentially pointless.

I think the key architectural point is that the current redo log is always vulnerable to loss, and there is nothing you can do to totally eliminate that risk. You can reduce it enormously by X-way multiplexing followed by X-way hardware mirroring. But the current redo is the weak spot, and if you lose that you lose committed transactions, as we know. All you achieve with a log switch is to make some other physical file the current log. Now of course that log starts off empty in a sense, but it won't be empty for very long (usually, at any rate).

>At least as of when I took the
> backup there is nothing in the redo (assuming a quiet time).

Incidentally, I'm not sure what you meant by saying "if a fire happens later that day then I have everything" You might have all the redo that is needed to recover the data files you backed up (though even that assumes a fair bit -ever discovered a backed up datafile to be corrupt on restore, and therefore have to go back one or more backups to find a clean copy?), but you certainly won't (I hope!) have copies of the online redo logs. Meaning, specifically, that you'll be missing the current redo log. That will require, even under your scenario, doing a recover until cancel followed by a resetlogs. So you don't even then get a perfect recovery, and a perfect clone at the end of it.

I really don't get fussed by people doing the log switch. If it makes them happy, fair enough. It;s not as if it kills them to do it. What worries me is that many (not necessarily you) do it because they think that somehow it makes things more safe and secure, more complete. More recoverable. But at the end of it all, there's a missing current log, and that means lost data. Trying to make a particular backup as close to perfect as you can seems to me to be missing the point: lose your current redo log, and you've lost data.

Think continuum, not one-off event.

Regards
HJR
>You are
> correct I probably should be mirroring my archive logs to a system that is
> not in the same geographic location; that would be a better idea.
>
> Jim
>
> "Howard J. Rogers" <dba_at_hjrdba.com> wrote in message
> news:a7o4ju$vfn$1_at_lust.ihug.co.nz...
> > If you're doing O/S online backups, then there's no need for a
preliminary
> > checkpoint, because that's precisely what the 'begin backup' command
> forces
> > (at least for the datafiles of the tablespace involved).
> >
> > The one about a preliminary log switch (presumably because you are about
> to
> > copy the archives) is always a curious one. Lots of people do it, and
> I've
> > never really understood why. Usually the justification is that without
> it,
> > you are short of the current redo log, so you may lose data. There's
> > something to that, I suppose. But it's also usually (so I find) because
> > people view a backup as an isolated event, whereas the truth of the
matter
> > is, of course, that what you don't backup tonight you will backup
> tomorrow.
> > So if there's a bit of current redo left unbacked up, who cares??
You'll
> > get it when tomorrow's backup is performed, and in the meantime there's
no
> > possible risk of data loss because you've multiplexed your online redo
> logs,
> > and then mirrored them with hardware RAID. Haven't you?? ;-)
> >
> > The other thing that mystifies me about forcing a log switch in order to
> get
> > an archive of the current log is that it only makes another log the
> current
> > log. So you can *never* really be completely and utterly up-to-date
with
> > redo copies, unless you stop all your users doing things: there'll
always
> be
> > a new piece of current redo which you haven't backed up today. Hence
cold
> > backups, of course.
> >
> > That said, a log switch does no real harm -except induce a
> > performance-hitting checkpoint.
> >
> > Regards
> > HJR
> > --
> > ------------------------------------------
> > Resources for Oracle : www.hjrdba.com
> > ============================
> >
> > "Glen A Stromquist" <gstromquist_at_nospamyahoo.com> wrote in message
> > news:jpMn8.11561$EV.366849_at_news1.telusplanet.net...
> > > In my online backup scripts I don't do a logfile switch or force a
> > > checkpoint before copying the datafiles.
> > >
> > > Is this recommended by Oracle?
> > >
> > > I'm wondering if I overlooked something when writing my scripts, I
have
> > used
> > > my online backups on occasion to create a clone db, so I know they
> "work"
> > > the way I'm doing it now, but I guess it can't hurt to build in a
> logfile
> > > switch and/or force a checkpoint as part of the script as well.
> > >
> > > Curious to hear what others do regarding this....
> > >
> > >
> > > cheers!
> > >
> > >
> >
> >
>
>
Received on Mon Mar 25 2002 - 21:13:14 CST