RE: archive_lag_target with real time apply for data guard
Date: Mon, 21 Dec 2015 09:12:49 -0500
Message-ID: <084601d13bf9$add5f1f0$0981d5d0$_at_rsiz.com>
Has anyone mentioned in this thread the primary purpose of archive_lag_target to allow you to safely send the updates off site without applying them so that in a case of application accident or malicious attack against the primary you may be able to intercept the application on the standby so you can instantiate the “before accident” state of data to evaluate the best possible result without doing a full recovery to a point in time?
Sigh. Yes, it also mitigates the production throughput overhead of max availability and max protection.
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of kathryn axelrod
Sent: Sunday, December 20, 2015 4:40 PM
To: oracle.blog3_at_gmail.com
Cc: Andrew Kerber; Oracle Mailing List
Subject: archive_lag_target with real time apply for data guard
Adding to what Andrew said, real time apply sends online log info..this may be sent anyway depending on other configs.
With max performance, it sends online log info when it's comitted on the primary..but the primary pays no attention to when the standby applies it.
You may want to consider switching to max availability with at least one standby using sync/affirm. It is a compromise between absolute 0 data loss and no primary downtime with minimal primary waits.
With max availability, as long as a standby is available, it sends info to the standby as soon as it's comitted to the primary's online log. (If no standby is available, it temporarily switches to max performance so the primary can continue).
With async/ noaffirm, the primary waits for the response that that standby received the data. Sync/ affirm = wait to hear the standby Applied the data.
Alternately, with max protection, it is 0 data loss..but the primary may shut down when it doesn't get a data confirmation from the standbys.
https://docs.oracle.com/database/121/SBYDB/protection.htm#SBYDB4743
On Sunday, December 20, 2015, max scalf <oracle.blog3_at_gmail.com> wrote:
Hi andrew,
so are you saying its okay to ignore that parameter on primary ?? as i am using asynchronous(max perf mode) with real time apply ?
On Sun, Dec 20, 2015 at 1:09 PM, Andrew Kerber <andrew.kerber_at_gmail.com> wrote:
As I understand the feature, it only applies to log switching. It was probably named that when asynchronous data guard was more common. It really only applies to recovery on the primary.
Sent from my iPad
On Dec 20, 2015, at 12:48 PM, max scalf <oracle.blog3_at_gmail.com> wrote:
Hello list,
We are in process of setting up data guard and one of the thing i was thinking was to set "archive_lag_target" to 1800 seconds, so that i do not loose my redo data on the standby site if there was a failure on primary, but then it also got me thinking, I am using real time apply(this is specific to 11g system). From what i understand about real-time apply is "it allows Data Guard to recover redo data from the current standby redo log as it is being filled by the RFS process", if that is the case why would i need to set archive_lag_target as my data is being pushed out anyways ??
thoughts ??
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Dec 21 2015 - 15:12:49 CET