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
-------------------------
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@xxxxxxxxxxxx
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: @NenadNoveljic
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@
freelists.org] *On Behalf Of *Andrew Kerber
*Sent:* Dienstag, 14. November 2017 16:25
*To:* contact@xxxxxxxx
*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@xxxxxxxx> 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: @OracleSK
Jack van Zanen <jack@xxxxxxxxxxxx> hat am 14. November 2017 um 04:21geschrieben:
Dataguard on the primary system?
Hi All
I was wondering if anyone had done any testing on the overhead of
can most likely not accept a performance degredation of the nightly batch
We would like to setup dataguard for one of our systems and the business
job.
the amount of nologging that is happening in the batch this could be a
Now I understand that we have to turn on force logging and depending on
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
//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.
