Re: Re[4]: 2 Node RAC Standby -- A mix of Managed Recovery and Read only?

The fear for loosing an archived redo log file implies that you don't
have redundant archive log destinations on your standby. They _should_
be redundant, especially because your standby is a candidate to become
primary. And that might happen because your primary is lost. So, when
the standby becomes primary, it's probably on its own. Therefore the
configuration of the standby should have redundant archive destinations,
among other important availability related measures, unless the access
policy for your building can keep Murphy outside.
Best regards,

Carel-Jan Engel

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

Upcoming appearances: 

      * Jan 27, 2005: London, UKOUG Unix SIG: Data Guard Best Practices 
      * Feb 9-10, 2005: Denver, RMOUG Training Days: Data Guard
        Performance Issues 
      * Mar 6-10, 2005: Dallas, Hotsos Symposium: Data Guard Performance
        Issues

On Fri, 2005-01-07 at 13:22, Kamus wrote: 

> the extra downtime is not the only risk.
> Image that if ur standby site has a disk failure (one archived log file
> is damaged), but at office time, u even don't try to recover these
> archivedlog, so u can't get any information from standby's alertlog said
> something is going wrong. then later at afternoon, you get a primary
> site failure ...
> 
> On Thu, 06 Jan 2005 20:20:40 +0100
> Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx> wrote:
> 
> > A read-only standby can continue receiving redo. So, the only risk is
> > extra downtime, because there is more redo to apply when the primary
> > fails whilst the standby is in R/O mode. Your description is a perfect
> > way of eating the cake and have it: run reports on the standby during
> > office hours, of course with data actualized up till the morning, and
> > let the standby apply the receive logs during the night. There is always
> > a standby, the recovery time of it may vary.
> > 
> > I didn't know of the 'mixed standby setup' you mentioned. Thank you for
> > bringing this up. Another challenge on my todo list for future tests.
> > 
> > Best regards,
> > 
> > Carel-Jan Engel
> > 
> > ===
> > If you think education is expensive, try ignorance. (Derek Bok)
> > ===
> > 
> > Upcoming appearances: 
> > 
> >       * Jan 27, 2005: London, UKOUG Unix SIG: Data Guard Best Practices 
> >       * Feb 9-10, 2005: Denver, RMOUG Training Days: Data Guard
> >         Performance Issues 
> >       * Mar 6-10, 2005: Dallas, Hotsos Symposium: Data Guard Performance
> >         Issues
> > 
> > 
> > On Thu, 2005-01-06 at 18:46, Steven Patenaude wrote:
> > 
> > > On Thu, 06 Jan 2005 20:02:17 +0800, Kamus <kamusis@xxxxxxxxx> wrote:
> > > > Sorry, I don't think so.
> > > > First, the storage is cheaper and cheaper this days, buy onemore cheap
> > > > dell-emc Storage System maybe enough.
> > > > Second, by setting up 2 independent standby databases we could get a
> > > > much more flexible anti-disaster environment. such as 1 be a physical
> > > > and the other be a logical, or 1 be a instant apply and the other be a
> > > > delayed apply, etc...
> > > 
> > > While _we_ know the one true way, management often doesn't agree that
> > > disk hardware, maintenance costs, datacenter floor space, etc. is
> > > cheap (or cheap enough).
> > > 
> > > I don't remember (and need to get on with my day job), does a standby
> > > database continue to catch the redo stream (but not apply it) while it
> > > is in readonly mode?  If so, you could alternate the standby between
> > > readonly and "catch up" modes as needed.
> > > 
> > > > Though oracle said standby database support RAC, at least so far I won't
> > > > use this function.
> > > 
> > > Obviously the standby can be configured for RAC but I agree about only
> > > having one instance up.  The documentation says you can have one
> > > instance catch the redo stream and another apply it.  Has anyone tried
> > > this?  It seems to me this would be added complexity (and chances for
> > > problems) with very minimal performance gains.
> > > 
> > > Steven
> > > --
> > > http://www.freelists.org/webpage/oracle-l
> > 
> > 





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

Other related posts: