Re: Online backup: Backup online redologs?

From: Howard J. Rogers <howardjr_at_www.com>
Date: Sat, 31 Mar 2001 20:42:12 +1000
Message-ID: <3ac5b4a5@news.iprimus.com.au>

"Jose Nicolau" <jose.nicolau_at_clix.pt> wrote in message news:3AC5E3D8.2FDA892A_at_clix.pt...
> "Howard J. Rogers" wrote:
>
> > "Vikas Agnihotri" <onlyforposting_at_yahoo.com> wrote in message
> > news:ata1cts3d70qan0bkbo9oa94i2eccsd0bd_at_4ax.com...
> > > Kevin Loney's Oracle 8 DBA handbook mentions the following 3-step
> > > process for a online/hot backup:
> > >
> > > 1. Backup each tablespace by putting it in backup mode
> > > 2. Backup the archived redologs (and optionally delete them to save
> > > space)
> > > 3. Backup the controlfile using ALTER DATABASE BACKUP CONTROLFILE
> > >
> > > Why is there no mention of the online redologs?
> >
> >

 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGHHHH


> > HHHHHHHHHHHHHHHHHHHHHH!

> > I don't beleieve this.
> > This was discussed at ENORMOUS length just last week. Don't you ever
 scan
> > other posts before sending off your own??
> >
> > Really.
> >
> > OK. <calm>.
> >
> > The basic rule in Oracle is this: you can't copy anything hot unless
 you've
> > a mechanism for making it consistent subsequently, because all hot
 copies
> > will be internally one big mess. Different bits copied at different
 times.
> >
> > Datafiles copied hot will be inconsistent. However, if you apply redo
 to
> > datafiles, they become consistent, and can then proceed to be rolled
 forward
> > to whatever time (read: SCN) you choose.
> >
> > Controlfiles copied hot will be inconistent. And you can't apply redo
 to
> > controlfiles. So they can't be made consistent... but fortunately, the
> > 'alter database backup controlfile to 'c:\blah\control01.bkp'" command
 makes
> > Oracle do the copying, and when Oracle is in charge it can use tricks
 and
> > techniques to guarantee the output will be read consistent. (Woe betide
> > you, however, if you *ever* do a simple O/S copy of a hot controlfile,
> > because it will be unuseable).
> >
> > Redo Logs copied hot will be inconsistent. And you can't apply redo to
 redo
> > logs. So they can't be made consistent.... and UNfortunately there is
 no
> > 'alter database' command that will generate consistent copies. So any
 hot
> > copies of redo logs will be inconsistent, will always be so, and will
 thus
> > be totally unuseable.
> >
>
> My hot backup, working whit 8.0.6, makes, at the end, a hot copy of the
 online
> redo logs, including the current. And, at recover time, I didn't see any
> problem so far.

Well, you want to stop that immediately. Oracle clearly and forcefully tells you not to hot copy redo logs, for the reasons I explained. The fact that you've got away with it once or twice does not make a lousy technique a good one. Hot copying redo logs is idiotic, not to put too fine a point on it.

I do a demo of cloning on the Backup and Recovery course, and re-naming the database after it's cloned. I knew that to rename the database there was a requirement to do a clean shutdown. But students get bored quickly whilst waiting for a clean shutdown, so I've always done aborts. And the database has been renamed perfectly every time. Except once, when I had just earlier demo'd a transaction -which therefore needed to be recovered after the shutdown abort... that conflicted with the need to re-create the controlfile.. and bingo! One stuffed cloning demo. The point of course is that particular circumstances, and special considerations might let you get away with a restore of hot copied redo logs (for example, if there are no transactions happening on the database whilst you take the copy, you might get away with it)... but that doesn't invalidate the principle. You should not take the backups in the first place, and you must not restore them.

Apart from anything else -by restoring a BACKUP of your redo logs, you've just over-written the CURRENT log -and that means you've lost information needed for complete recovery.

> I know, if it's possible, I'll preserve the redo log files on disk (after
 a
> failure).
> What are the options for a total failure of a database with a hot backup
 and
> some archived redos?
> I tried to recreate the redo logs in mount mode, but 'he' is always asking
 me
> about the lost redos.
>
> >
> > And then there's this: think about it. If you are in archivelog mode,
 you
> > *do* have a consistent copy of the redo logs in the archive log (which
 is
> > 'cold' the second it is written). So by backing up the archivelogs, you
 are
> > in effect backing up consistent copies of the online redo logs. The
 only
> > exception is the CURRENT redo log, which is hot, hasn't been archived,
 and
> > cannot be O/S copied. This is the potential achilles' heel of the
 Oracle
> > database. Loss of the current log will result in data loss -but that's
 why
> > redo log mirroring was invented, to make the potential total loss of the
> > current log extremely unlikely.
>
> ...but possible...
>

Yes. It's *possible* there'll be a nuclear war tomorrrow, as well. You can't really ever guarantee never losing all copies of a log group. Mirroring is just a sensible insurance policy.

> >
> >
> > >During BEGIN BACKUP,
> > > arent the changed blocks written to the online redologs (in addition
> > > to the datafiles themselves)? So, if my entire backup is over before
> > > the online logs cycle, my online backup will be missing the changes
> > > generated during the backup since they are present only in the online
> > > redologs, right? What am I missing?
> > >
> >
> > You are missing the usual recommendation from Oracle, which is to issue
 an
> > 'alter system switch log file' command at the end of each tablespace's
 spell
> > in hot backup mode.
> >
>
> I'm making a switch log at the begin and another switch at the end of all
> tablespaces. Am I right?

No. Not really. It's better than nothing. But you might have a failure during the hot backup that takes out your redo logs entirely. At which point, you've lost the block-level redo, since no archive log has been produced. A switch every tablespace at least minimises the amount of data you'd lose in that scenario.

Regards
HJR
> Or are you talking about backing up only one tablespace?
>
> >
> > > And if the online redologs should indeed be backed up, shouldnt there
> > > be a BEGIN BACKUP for them as well since they are in a state of flux?
> > >
> >
> > See above. It makes no sense to backup the online redo logs. They've
> > already all been backed up to the archives, with the exception of the
> > current log. If you are that concerned, then a switch log file will
 cause
> > that to be archived, and by backing up that last archive, you've got the
> > lot.
> >
> > Regards
> > HJR
> >
> > > Thanks...
>
> Thanks in advance by your opinion HJR.
>
> José Nicolau
>
Received on Sat Mar 31 2001 - 04:42:12 CST