Well, not quite. If you are in max availability mode, and your primary falls
back into asynchronous mode, then you need to be concerned. Also, oracle still
recommends that log switches still occur at least 3 times/hour the last time I
checked, and I use the parameter regularly to ensure switches happen often
enough.
Sent from my iPad
On Dec 20, 2015, at 1:13 PM, max scalf <oracle.blog3@xxxxxxxxx> 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@xxxxxxxxx>
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@xxxxxxxxx> 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 ??
