RE: [SPAM] RE: Overhead of Dataguard

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Fri, 17 Nov 2017 08:30:12 -0500
Message-ID: <028101d35fa8$4a937ac0$dfba7040$_at_rsiz.com>



And if that IS a requirement, be certain to at least learn whether Axxana with maximum performance is functionally equivalent for your use case.  

(Not paid in any way by Axxana, just a big fan of their concept and implementation of a solution for grabbing everything through the last commit with no upstream overhead.)  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of John Thomas Sent: Thursday, November 16, 2017 5:24 PM To: jack_at_vanzanen.com
Cc: Noveljic Nenad; andrew.kerber_at_gmail.com; contact_at_soocs.de; ORACLE-L Subject: Re: [SPAM] RE: Overhead of Dataguard  

Haven't seen a mention of "Far Sync" in this chain. Just mention it in case the requirement is for synchronous redo transmission and low latency but guaranteed no data loss...  

Regards,  

JT  

On Tue, 14 Nov 2017 at 22:12 Jack van Zanen <jack_at_vanzanen.com> wrote:

The reason we need a DR is to move it to new hardware with minimal down time on cutover weekend  

This specific database does not have a DR setup yet...it is a BI environment and every night a batch job runs to update/refresh data.  

We have no control over the ETL (third party vendor) so I don't have insights as to how much nologging is going on, but the vendor has confirmed that there will be overhead/performance impact (makes sense to have nologging in a ETL)  

It is just that in my experience with maximum performance the overhead of dataguard is pretty minimal and the only issue that really affects performance is turning on force logging (which can be somewhat mitigated by making sure the logs are on the fastest available disks and maybe add some groups to handle the peaks).  

So my thought is:  

Turn on force logging and see how bad it gets with current setup...if negligible impact, setup DR using maximum performance and see how far we fall behind...

If that works move to higher level of protection..    

Jack van Zanen  

  <https://docs.google.com/uc?id=0BwovDucFT1fXaEREVHNWRWZyNjg&export=download>



This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Thank you for your cooperation  

On Wed, Nov 15, 2017 at 2:38 AM, Noveljic Nenad <nenad.noveljic_at_vontobel.com> wrote:

I’d like to add that if you configure the data guard to run in max protection mode or max availability mode (synchronous replication!) the laws of physics will inevitably kick in. What I mean by that is the latency will be constrained by the physical distance between the data centers.  

Nenad  

http://nenadnoveljic.com

Twitter: _at_NenadNoveljic    

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Andrew Kerber Sent: Dienstag, 14. November 2017 16:25
To: contact_at_soocs.de
Cc: Jack van Zanen; ORACLE-L Subject: Re: Overhead of Dataguard  

I have done a lot of work with Dataguard in just about any conceivable scenario. The issue you mention, force logging, is the only place where there could in theory be an impact on performance, Even that can be prevented with proper configuration of your redo logs. I have never, however, seen dataguard have a noticeable impact on performance.  

On Tue, Nov 14, 2017 at 2:57 AM, Stefan Koehler <contact_at_soocs.de> wrote:

Hey Jack,
you may want to have a look at this white paper: http://www.oracle.com/technetwork/database/availability/maa-wp-10gr2-dataguardnetworkbestpr-134557.pdf

It is about Oracle 10g and there have some enhancements in the meantime but it includes impact analysis / results.

Best Regards
Stefan Koehler

Independent Oracle performance consultant and researcher Website: http://www.soocs.de
Twitter: _at_OracleSK

> Jack van Zanen <jack_at_vanzanen.com> hat am 14. November 2017 um 04:21 geschrieben:
>
> Hi All
>
> I was wondering if anyone had done any testing on the overhead of Dataguard on the primary system?
>
> We would like to setup dataguard for one of our systems and the business can most likely not accept a performance degredation of the nightly batch job.
>
> Now I understand that we have to turn on force logging and depending on the amount of nologging that is happening in the batch this could be a considerable overhead, I am just wondering besides this what the impacts are in maximum performance and maximum availability and maximum protection mode. I can turn on force logging without having to set up dataguard.
>
> Let's assume for now that the network can keep up with the changes.....
>
> Jack van Zanen

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




-- 

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

____________________________________________________

Please consider the environment before printing this e-mail.

Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.


Important Notice 
This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system. 
E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.

 

-- 

Regards, 

John 



--
http://www.freelists.org/webpage/oracle-l
Received on Fri Nov 17 2017 - 14:30:12 CET

Original text of this message