Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: hanging shutdowns, excellent case for a standby recovery database and associated frozen rename target

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

From: Carel-Jan Engel <>
Date: Tue, 28 Feb 2006 22:58:57 +0100
Message-Id: <>


What type of DR site is discussed then? Remote, or in the same data center? EMC BCV's, SRDF, or something else? Marks excellent ideas work best when you do not use storaged-based replication, but Data Guard. Of course EMC will like Marks solution very much. But EMC likes Marks ideas anyway. If you go for SRDF/BCV like stuff, EMC can sell even more disks to do the whole operation Mark suggested. I'd like to suggest not to go for this expensive stuff.

If you think of Data Guard (hey, why should I chime in ;-) ) you save lots of bandwidth, lots of disks, and you could shutdown the standby database on a regular interval, and go for Marks gameplan cloning the standby etc. Of course your redo forwarding stops during that interval, giving you less data protection. Another option is to put the standby in read-only mode, and make the clone of this open (R/O!) database. No archives get applied, the database isn't changed, redo information is still received by the standby. Again, continue with Marks plan from step 3. This way you can have your cake and eat it.

A last way is to take a hot backup, use it for recovery on your 'legal server' (or to a renamed copy-database), do all the point in time recovery, rollback processing, block cleanouts and whatever, shut it down properly and make the cold backup.

RMAN is wonderful for the cloning process, Data Guard for standby. Either of these can help you to complete the legal task without shutting down the production database. The copy database helps you to gain routine in the task, it helps you making the legal dept. confident that you can provide a database that meets their requirements. You might be able to agree with them on some formal proof of the usability of the database. Let them enter some verification data in the database, (random numbers at predefined timestamps you don't know?), enabling you to prove that the backup is representing an exact timestamp, without fiddling around with it: plain open database, and there it is.

HTH, Best regards,

Carel-Jan Engel

If you think education is expensive, try ignorance. (Derek Bok) ===

On Tue, 2006-02-28 at 14:00 -0500, Robyn wrote:

> Mark,
> Thank you for the ideas. We are already having discussions with
> Oracle (and EMC) about setting up a complete hot backup site. Perhaps
> the points you made below will help us gather the funding required as
> the price tag still has mgmt reeling. However, the project has been
> given a high priority so there is a very good chance we will pursue it
> later this year.
> I'm going to do a little more research on the delayed block cleanout
> issue so I can present the concepts clearly to the less-technically
> oriented. If you have any suggestions on materials, I'd appreciate a
> pointer.
> Thank you again ... this presents some interesting discussion points.
> Robyn
> On 2/28/06, Mark W. Farnham <> wrote:
> > 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:
> > []On Behalf Of Robyn
> > Sent: Tuesday, February 28, 2006 9:58 AM
> > To:
> > Cc: Oracle-L_at_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
> >
> >
> >
> --
> Robyn Anderson Sands
> email:
> --

Received on Tue Feb 28 2006 - 15:58:57 CST

Original text of this message