Open redo log vs Open archive log
Ram Dittakavi, September 04, 2017 - 5:48 am UTC
It says in the above thread that an open archive log cannot be used for failover. Why not ? And how an open standby redo log can be used for failover ? Don't understand the difference and why ?
September 05, 2017 - 6:43 am UTC
"It says in the above thread that an open archive log cannot be used for failover. Why not ?"
Because it can't. It is a limitation that standby redo logs overcomes.
Transactionally Identical
Ram Dittakavi, September 04, 2017 - 6:51 am UTC
Hi Connor,
Below is an excerpt from documentation :
http://docs.oracle.com/database/121/DGBKR/dbresource.htm#DGBKR220 "By default, no delay is configured and the redo data is applied on a standby database as soon as possible. If the standby database has standby redo logs configured, the broker will enable real-time apply. When Redo Apply and SQL Apply apply redo in real time, the redo data is recovered directly from the standby redo log files as they are being filled. This means that the standby database does not have to wait for the log files to be archived before applying redo data from the archived redo log files. This minimizes the transactional lag between the primary and the standby."
Here it says, in real time apply, mrp reads from standby redo logs as it is being filled not after the log switch which actually makes sense as it tries to be transactionally identical to the primary. But as per you in the above mentioned thread, mrp starts reading from standby redo only after a log switch on the primary side.
This is causing confusion. I believe, the true purpose of standby redo logs is to have real time apply which allows MRP to read from standby redo logs as and when a transaction is committed on primary and that redo is written to the standby redo logs but not wait until a log switch on primary.
September 05, 2017 - 6:42 am UTC
"Here it says, in real time apply, mrp reads from standby redo logs as it is being filled not after the log switch which actually makes sense as it tries to be transactionally identical to the primary. But as per you in the above mentioned thread, mrp starts reading from standby redo only after a log switch on the primary side."
Because if you lose the primary, those remote writes to the SRL have been done. If you dont have SRL, then you only write at log switch time. Which means you could lose a whole redo log worth of transactions. That could be *gigabytes*
Apply Delay > 0
Ram, September 06, 2017 - 6:17 am UTC
Thanks Connor for confirming that the mrp recovers the standby database by reading from standby redo logs as they are getting filled instead of waiting for a log switch in the primary.
One more question: If we have configured an apply delay > 0, then archive logs are used by mrp for recovery right? since standby redo logs would have got re-used already for the next set of transactions.
September 07, 2017 - 2:32 am UTC
There is no fixed link between redo and standby redo, ie, just because we are on redo log group 3, does not mean we are using standby redo log group 3. When redo is fired across to the standby, it is simply of case of "which standy redo is available", which is why often it appears that only 1 (or 2) standby redo's are actively in use.
Apply Delay > 0
Ram Dittakavi, September 08, 2017 - 7:07 am UTC
Suppose, i have set the delay as 240 mins (4 hours) and let's say the primary database generates 2 archives every 30 mins and i have only 4 standby redo log groups.
In this setup, all the standby redo groups must be used atleast once or if only 2 groups are being used, the redo stream written now (this very minute) must have have been overwritten in next 4 hours for sure.
Now, mrp has to read from archives to recover the database correct ?
Ram Dittakavi, September 13, 2017 - 5:32 am UTC
Can i get a reply please?
September 13, 2017 - 7:15 am UTC
Well... you *were* going to get a reply.
Follow up
Ram Dittakavi, September 18, 2017 - 12:45 pm UTC
Hi Connor,
Can you kindly confirm if my understanding is right?