Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: DataGuard

RE: DataGuard

From: Allen, Brandon <Brandon.Allen_at_OneNeck.com>
Date: Mon, 15 Jan 2007 16:48:59 -0700
Message-ID: <04DDF147ED3A0D42B48A48A18D574C45059E2816@NT15.oneneck.corp>


I'm not questioning Carel-Jan's recommendation at all - I think he has more DG knowledge in his pinky than I'll ever have, but just passing on a case where cascading setup might be appropriate/necessary:  

We have been struggling to get a standard (single standby) DG setup working for the last few months because our network connection isn't sufficient to keep up with the rate of our redo generation and when the transfer of archived logs falls behind far enough, it eventually freezes the production database. We're using ARCH to transfer the logs and already tried upgrading to 9.2.0.8 and setting the hidden parameter
_log_archive_callout='LOCAL_FIRST=true', but we still see this behavior.
Oracle Support's recommendation is to implement a cascading standby where we ship the logs to a local standby first and then go from the local to the remote so that the local standby operates as a buffer to keep the slow network from halting our primary. We are considering their recommendation, but going to try everything else we can think of to avoid it first, which will probably include upgrading to 10.2 because supposedly this problem no longer occurs in 10g, but that's the same thing we were told about 9.2.0.7 with the local_first=true setting (Metalink 260040.1) and we're not very confident based on our experience with that config.  

Of course another option that we're considering is increasing the network bandwidth to the remote destination, but we would really like to have dataguard configured such that it will absolutely never impair production performance because even with the increased bandwidth, there is always the possibility of WAN problems, someone accidentally clogging the pipe with other large files, etc.  

Carel-Jan, if you have any recommendations, we'd love to hear them!  

Thanks,
Brandon  


From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Carel-Jan Engel Sent: Monday, January 15, 2007 4:12 PM

Stay away from cascaded redo transport as far as you can. You simply don't want that in HA environments. As Miracleas.dk states: '..Complexity is the enemy of availability...' (and I'd like to add: '.. but the friend of consultancy...' J). Imagine a switchover with cascaded transport. The whole redo transport stack has to be reinvented. A star-configuration (primary points to both standbys) is much easier to setup.

Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Jan 15 2007 - 17:48:59 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US