Tesla S, November 15, 2016 - 3:37 am UTC
Thanks Connor.
When you say applied immediately in case of Standby Redo, does it apply immediately without waiting for a log switch to occur in primary even in the case of ASYNC mode?
Correct me if I'm wrong, I doubt it since Standby Redo makes sense when it comes to SYNC apply.
Then if it applies in real time basis in ASYNC mode, why would one prefer Synchronous mode over ASYNC?
November 16, 2016 - 4:15 am UTC
From MOS note 219344.1
4. Differents in the Log Apply Services when using Standby Redo Logs
--------------------------------------------------------------------
In case you do not have Standby Redo Logs, an Archived Redo Log is created by the RFS process and when it has completed,
this Archived Redo Log is appliedto the Standby Database by the MRP (Managed Recovery Process) or the Logical
Apply in Oracle 10g when using Logical Standby. An open (not fully written) ArchiveLog file cannot be applied on the
Standby Database and will not be used in a Failover situation. This causes a certain data loss.
If you have Standby Redo Logs, the RFS process will write into the Standby Redo Log as mentioned above and when a
log switch occurs, the Archiver Process of the Standby Database will archive this Standby Redo Log to an Archived Redo Log,
while the MRP process applies the information to the Standby Database. In a Failover situation, you will also have access to the
information already written in the Standby Redo Logs, so the information will not be lost.
Sync vs Async
Tesla, November 16, 2016 - 3:10 pm UTC
Ok. If I use real-time apply even in case of maximum performance mode, then I get a simliar end result to that of using Maximum Availability where it is synchronous transfer.
Why would I prefer SYNC (Max Availability) over ASYNC (Max. Performance) when ASYNC has the Standby database in real time sync (when using real-time apply)?
November 17, 2016 - 2:43 am UTC
SYNC *guarantees* that the two databases are identical. Commit works on both, or none at all.
ASYNC gets close but there is *no* guarantee. If you lose the network, the standby is allowed to drift out of date.
They serve different business requirements.
Lag target vs SRL
Tesla, November 19, 2016 - 3:51 am UTC
For me to keep standby in sync with primary on real time basis, if im not using standby redo logs, is archive_lag_target is the parameter that i should set to keep the standby in sync which induces log switches in primary?
archive_lag_target or standby redo logs - which one do you prefer when in case of Max performance mode?
November 21, 2016 - 1:21 am UTC
Definitely standby redo logs. If you bring archive target down to a very low value, you'll be switching logs all the time
Log switch query
Tesla, November 26, 2016 - 6:07 pm UTC
Connor, referring to your first response, you mentioned without standby redo, - 'that will be applied at log switch time'
Do you refer to log switch at primary or standby?
Also, with standby redo, you said it gets applied immediately - can you explain a bit more here?
Just to get bit more clarity. Thanks in advance!
November 27, 2016 - 7:52 am UTC
(Assuming a standby redo log is present) my understanding of the process is:
- I write some redo on the primary and commit
- I dispatch that redo off to the standby
- It is written "immediately" to a standby redo log.
- A log switch will occur on the primary before the standby due to the restriction as per docs:
"Each standby redo log file must be at least as large as the largest redo log file in the redo log of the redo source database"
- at this point, the standby archives the standby redo log and applies it.
Tesla, November 27, 2016 - 8:01 am UTC
Ok even in the case of standby redo, when you say it applies it in standby database only after the log switch in primary, it does not mean it is real time right?
It may be immediately written to standby redo but it applies only after log switch in primary?
This is similar to that of a scenario without standby redo right - meaning the redo is written to a archive log and it is applied again when log switch occurs in primary.
Ultimately the redo is received in one form or another but apply depends on when log switch occurs in primary.
Correct my understanding.
November 28, 2016 - 2:45 am UTC
Without standby redo logs
- we write them to archive logs. See the previous reviews
"An open (not fully written) ArchiveLog file cannot be applied on the
Standby Database and will not be used in a Failover situation. This causes a certain data loss."
With standby redo logs
- we write them to standby redo logs.
These *CAN* be used during failover to (almost) eliminate data loss.
Clarity on log switch
A reader, January 11, 2017 - 6:33 am UTC
Hi, can you elaborate bit on "Each standby redo log file must be at least as large as the largest redo log file in the redo log of the redo source database"?
I'm unable to get that point.
January 12, 2017 - 1:53 am UTC
The standby logs are not "paired" to any particular redo log. So I could be writing to redo log #1, and the changes are written to standby log #7.
So you need to make sure any given standby log can accommodate the changes from any given redo log.
AR, February 20, 2017 - 6:40 am UTC
Ok standby redo must accommodate redo source at every point in time, that is fine but how that is significant or related to 'redo switch has to happen first in primary first and then on standby'
February 21, 2017 - 1:52 am UTC
My understanding is that the log switch on the primary is the trigger for the archival of the *standby* redo log, hence the restriction.