RE: Question in HOT BACKUP

The argument I generally use here is:
1.)  In the case of a hot backup, there is no mechanism
by which you can get a consistent copy of on-line redo.
2.)  In the case of a cold backup, step 1 is ALWAYS a=20
clean, normal (non-aborted) shutdown.  If that's true,
then the on-line redo doesn't contain any useful information.

Given that, never, ever, backup your on-line redo log.

-Mark

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Mark W. Farnham
Sent: Saturday, October 02, 2004 9:53 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Question in HOT BACKUP


Just a bit more:

1) The first step of recovery is to get a secure copy of whatever the =
state
is of the current online redo logs. This is before you restart the =
instance,
the files are cold, and it gives you a chance to try again if there is =
pilot
error or a physical problem with the machine during recovery. You do =
this
before you start hanging tapes or "silvering" from an online backup set. =
If
you reach "open resetlogs" and you have a problem, that is when you =
realize
you made a silly mistake. I hesitate to call this a backup of the online
redo logs, since I consider it part of recovery, and see #2.

2) It is an unwinnable nearly religious war whether you are better off =
with
the online logs on the backup sets. (My particular faith in this matter =
is
hotbackups should never include online redo logs, cold backups only if =
the
site procedures include step #1 and an alternate reload location naming
scheme, and only do cold backups if your situation allows time for a
shutdown normal.) If you do the double dip shutdown (abnormal), startup
restrict, shutdown normal for cold backups, then no transactions from =
the
online logs are needed, so if you happen to reload an entire cold backup
tape to use for roll forward, all you have done is create risk that the
online redo logs will be overwritten by a possibly Oracle ignorant =
computer
operator. On the other hand, if your "cold backup" is not from a clean
shutdown, if you try to load it up and start the database you will =
likely
need transactions from the online redo logs from the non-clean shutdown. =
For
those whose "religion" on this matter differs from mine, I suggest that =
you
write the on line redo logs to a separate tape set and see if you ever =
need
them in any scenario you can create on your test restore machine. (If =
you
don't have a test restore machine, you don't take recovery seriously,
anyway.) Of course this excludes the well-known fact that the cold =
backup of
a shutdown abort is likely to need the online logs, because I advise =
against
that particular backup anyway. In the event of a machine crash you have =
to
evaluate whether there is time for a complete save before you restart.
FIRST, get a copy of the online logs just as they are. Then think about =
a
complete save set and/or splitting off your third plex before you =
procedure.
This is a slippery slope argument where your particular situation and
resources dictate what you should do. Usually machine crash restarts go
smoothly because Bill Bridge is a very wise and careful person.

3) If you are building internally complete hot backup sets, remember to
alter system switch logfile after all tablespaces are out of backup, =
wait
for archive to complete and include all archived redo logs from the =
start of
the first tablespace begin backup through the redo you switched out of =
after
the last end backup. If you're paranoid, start one earlier and switch =
and
wait twice at the end. These are not really needed, but if the person
scripting up the copy of arch for the internally complete hot backup set =
is
fencepost challenged you still get the right answer.

(Draw a picture of a barbed wire fence and count the posts and segments =
of
fence if you are not familiar with that term.)

May you sleep well knowing your backup that you never hope to use will =
work
because you test it every {day|week|not much longer than that} on your =
test
recovery system!

mwf

PS: Think about RMAN, but I've got no criticism for those who want to =
wear a
belt and braces (suspenders) by having both RMAN backups and "hot" =
backups.

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Jeremiah Wilton
Sent: Saturday, October 02, 2004 6:28 AM
To: Chirag DBA
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Question in HOT BACKUP


On Sat, 2 Oct 2004, Chirag DBA wrote:

> When I was asked which filese I will copy for hot backup, I said redo =
too.
>
> Cause I think they can help us always to recover database upto point =
of
time.
>
> I was pulled a lot, but my only question that if not redo then how
> will you recover yr DB upto point of failure, stopped the arguements.

Askdba removed from the distribution.

If you can win the argument, you must be right!  Anyway good for you
for checking on this even though you convinced the interviewers you
were right.

The reason that many people recommend against backing up online logs
during hot/cold backup is twofold:

1. If you back up the current online log, you have no guarantee of
obtaining a clean copy since log writer might be halfway through
performing a write.  You should obtain the most recent log by
archiving it (archive log current).

2. If you restore a backup including the online logs (in their normal
location) and the controlfile is also restored in the normal location,
then the restored database can be brought up in such a way that crash
recovery would take place automatically without prompts, and there
could be no opportunity to apply archive logs to roll the database
forward to a future point in time.

It is likely that you might want to recover past the point in time of
the backup, thus the online logs would be nowhere near the most
current logs for the purposes of a restore/recover exercise.

--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton
--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l

Other related posts: