This content has been marked as final. Show 6 replies
I generally recommend not enabling this feature ... in fact I am far more inclined to build in an intentional apply delay ... here's why.
Suppose something really bad happens in the primary ... it will be immediately replicated to the standby ... now both have the problem. I like an apply delay sufficient to catch issues and, perhaps, prevent the apply.
in fact I am far more inclined to build in an intentional apply delayThat would be the case when building more than one standby OR if the standby isn't intended as a real DR site.
If there is a single standby and it is the real DR site, management would want real-time or the minimal lag achieveable. Advicing a second standby with an apply delay would be a good thing.
Hemant K Chitale
I understand your point but if they are not expecting transparent failover ... I always try to argue for a delay. I may not get it ... but I try.
994949 wrote:Corrupted blocks on primary database are automatically repaired.
1)Are there any advantages other than the above to enable the real time apply feature for a physical standby?
Incremental backup's on physical standby is possible.
2)What is the recommended way (enable or disable real time apply) and Why is that so?For active dataguard you need to get license.
Some times it is not recommended for the clients if they need a minimum xyz minute gap difference btw primary and standby(though it is possible in ADG also).
yet the recommended one : it depends upon the requirement.
Its best to explain & leave the decision for the customer/clients/developer.
Corrupted blocks on primary database are automatically repaired.Hi, Veeresh.S. i listen this first time . Can u provide some documents' link for me ?
You are confusing Real-Time Apply (10g New Feature) with Real-Time Query (11g New Feature, requiring the additional Active Data Guard option).
"Don't believe it, test it!"