Re: archive_lag_target with real time apply for data guard

From: kathryn axelrod <kat.axe_at_gmail.com>
Date: Sun, 20 Dec 2015 15:55:11 -0800
Message-ID: <CAEbHM44RrqYFpD0JbSYLUpg+mBH8HMgGrDMs_zXc-CkzSXK+oQ_at_mail.gmail.com>

Indeed, 'significant' depends on the environment and business needs. In this case, he seemed more concerned about data loss, so max availability may be worth looking into.

On Sunday, December 20, 2015, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

> On 12/20/2015 04:39 PM, kathryn axelrod wrote:
>
>> 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
>>
>>
>>
>> There is a significant performance penalty for both maximum availability
> and maximum protection. Most of the places I've seen run in maximum
> performance mode. The choice depends on the business needs.
>
> --
> Mladen Gogala
> Oracle DBA
> http://mgogala.freehostia.com
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

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

Received on Mon Dec 21 2015 - 00:55:11 CET