Re: [SPAM] RE: Overhead of Dataguard

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

> 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.
>

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