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

  • From: Robyn <robyn.sands@xxxxxxxxx>
  • To: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
  • Date: Tue, 28 Feb 2006 17:00:08 -0500


I found the doc and it does provide a great example that should be
clear to most of the those I would need to have discussions with.

At this point, I figure the best course of action is:

1.  Alter the scripts to use startup force restrict / shutdown
immediate with a forced checkpoint.  (Already tested and deployed so
I'm set for this weekends backup.)

2.  Work toward the hot standby site with our systems people.  (It's
actually their initiative.)

3.  Use the info provided by Mark to show exactly what we would have
to do to provide the "truly frozen point in time immutable database"
and hopefully convince everyone once and for all that the current cold
backups are not providing what everyone seems to think they are
providing.  Of course, this could result in someone deciding we should
complete this process on weekly basis, but given the desire to
maintain minimal staffing levels, I think the risk of that is pretty
low.  Worst case, maybe we'd have to build the TFPITID for legal once
a quarter.

Thanks to everyone ...


On 2/28/06, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote:
> Metalink note 40689.1 has a good explanation of delayed block cleanout.
> Regards,
> Brandon

Other related posts: