Re: Active Dataguard -- Cascade Standby or not
Date: Mon, 5 Dec 2011 15:39:36 -0500
Message-ID: <CAFk4TtVigFDEnChYQychfCjDUGAQEXruLgncUEHvbXN8onzRLQ_at_mail.gmail.com>
short answer to your question is: yes the tradeoff you mention is correct, and adg will work just fine in a cascaded configuration. The real pita with such a configuration is that you can't easily feed it to a broker, you're going to need to maintain the parameters yourself - which does work. realize that you effectively only will have arch transport for cascaded redo, so your log archival interval will determine your latency. Key things that I've seen:
- Knowledge skew: your application has to be able to handle the reality that reads after write/commit if the read is performed against the ADG systems may not be consistent. For some types of logic, this can be a rather important.
- Network bandwidth. if you really scale up or generate a lot of logs, you may need to have some sort of cascade tree. This can magnify the above problem in that different standby systems will have different amounts of skew
- Parameters getting lost through variety of means. You'll probably want to have something which properly sets the non broker managed parameters if they suddenly vanish
- Various other kibbles and bits of monitoring (measure skew, availability, etc)
- You likely will want to setup/configure standby statspack or write your own stuff querying the v$ views and aggregating the data somehow if you are interested in obtaining metrics for standby performance/utilization.
- Pay attention to preferred fal servers; one thing you may not want is a standby to come up after an extended outage and immediately request a bazillion GB worth of logs from the primary and effectively brown out its network interface transferring logs
- Make sure your single instance ADG systems can apply fast enough to keep
up with log generation on the cluster. This is part of where monitoring may
help. You'll at least want to be aware of any possible situation where the
primary is emitting logs faster than the standby can apply them -- if it is
capable of so doing.
- craig
On Wed, Nov 30, 2011 at 8:24 PM, Stalin <stalinsk_at_gmail.com> wrote:
> We have a requirement from one of our customer to have up to 15 ReadOnly DB
> sites all replicating data from so called primary site. Active dataguard
> seems to be a perfect fit but I was wondering the impact on the primary
> site in replicating data to all 15 readonly Active physical standbys. Only
> one standby site will be the failover target and configured in SYNC
> Availablity mode and rest in ASYNC Performance mode. Also, i was wondering
> if having a cascade standby's instead of having primary site to replicate
> all standby's a viable option to reduce load on primary with the trade off
> in additional lags from standby.
> If anyone could share your experences or things to watch for in similar
> setup is greatly appreciated.
>
> --
> Thanks,
>
> Stalin
> PS. 11.2.0.2 RAC (Primary), 11.2.0.2 (Standby, Single Instance), Linux
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
--
.- ... . -.-. .-. . - -- . ... ... .- --. .
Craig I. Hagan
hagan(at)cih.com
"If you aren't getting something for nothing, you're not getting your fair
share."
- Huey Long
--
http://www.freelists.org/webpage/oracle-l
Received on Mon Dec 05 2011 - 14:39:36 CST