RE: hanging shutdowns, excellent case for a standby recovery database and associated frozen rename target

Robyn:

This seems to me like an excellent case for Alexandrian logic; don't untie
the knot, hack it apart!

One point I've missed in this thread is ensuring that rollbacks are complete
so that neither infinitesmal chances of failure of roll forward nor rollback
exist in your cold backup. Since whatever release it was when the ability to
open the database before all rollbacks are complete implemented, the side
effect of pending rollbacks in "cold" backups has from time to time been
ignored.

Another point is delayed block cleanout.

If what your legal department really wants is a cold backup in the sense
that all the files can be immutably stamped with a date last modified and
starting the database does not execute changes to the files, then a mere
cold backup is in fact not enough.

So make the legal department your ally, who will then provide support for
you to have a standby-failover site. To create your truly frozen point in
time immutable database you then would:

1) Cancel recovery on the standby.
2) Copy the standby (locally on the standby site, or to yet another server
if you want to avoid the rename database step).
3) (Optional depending on your choice in step 2.) Rename the copy.
4) Recover the COPY of the cancelled recovery standby to an exact known
point in time.
5) Comprehensively query all blocks and do whatever else you have to do to
trigger all delayed block cleanouts (I think that is version dependent and
I'm not sure I've seen a comprehensive update on that issue since the last
time I was somewhat confident I thought I knew how to do that, references to
a comprehensive discussion welcome).
6) Shut down the cleaned out copy cold.
7) Copy the cleaned out copy to whatever backup media your legal department
and you can agree on as sufficient.
8) Resume remote recovery on the standby. (Actually you can do this after
step 2 if your choice is a remote machine).

If you have an alternate server, you could also just hot backup to there and
do the similar function of starting up and completing recovery, rollback,
and "cleanout" to produce a very clean cold shutdown.

All this avoids the shutdown on the primary production database altogether
but still gives you a cold backup which is arguably a superior cold backup
to the kind that may contain pending rollbacks and delayed block cleanouts.

Now if I've botched something in this logic, all y'all please be kind, but
additions/corrections/etc. are certainly most welcome.

Regards,

Mark


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Robyn
Sent: Tuesday, February 28, 2006 9:58 AM
To: m.haddon@xxxxxxxxxxx
Cc: Oracle-L@Freelists
Subject: Re: hanging shutdowns


Micheal,

I understand your position and when I arrived here, I made all the
same arguments.  I've been told that our legal department insists on a
cold backup, and the requirement is non-negotiable.  We run full test
recoveries on all our major systems on a regular basis and we use the
hot backups to do so.  None of us doubt that the hot backups are
adequate for recovery.

So I guess we're not really 24x7, we're 24x7-15 and that 15 minutes is
a sacred cow that I need to leave alone right now ...

Thanks for the input and if I was calling the shots,  I wouldn't do it
this way.  However, I would still need a script that would shut the
database down quickly, possibly for maintenance or hardware issues, so
I really appreciate the suggestions provided on this thread.

Robyn


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

Other related posts: