Hi Connor,
Thank you for your continous help and reply.
To avoid ambiguility, the protection mode being use is best performance.
It means that eventually you could exhaust available SRL
- When does oracle dataguard decides it could reuse an SRL ?
- When does it decides that the MRP can no longer catch up with the redos generated and decided to switch to archive log ?
=========================
In max performance/avail mode, my understanding is that the moment we logswitch, we'll change to a new SRL, and archive the old one. Incoming redo will just be directed into the new SRL.
- Do you mean redo entries belonging to a particular sequence# can be split across 2 different SRLs and eventually different archivelog ? I have never seen a sequence# split across 2 archivelogs in standby.
What i mean is Primary Redolog#1 with seq#1234 has (for e.g. 200 redo entries ), and the network between the primary and stnadby is extremely slow. These redo entries are being received into SRL#1
While sending redo entry #124 (out of 200), there is a logswtich on Primary Redolog#1 , what will happen to redo entry #125, and the current SRL ?
if the current SRL is switch out also, for the same sequence#1234, redo entry #1 to #124 is in SRL#1 and redo entries #125 to #200 is in SRL#2 ?
=====================================
Just in case you are thinking why i am trying to understand the internal mechanisms ->
Reason for asking these is because i am encountering a phenomenal whereby
i) after a surge in logswitches
ii) followed by immediate low database activity,
iii) even though all required archivelogs are already applied, standby is still reflecting a high A-LAG and 0 T-LAG.
The A-LAG is the duration (first_time, to next_time) of the current ORL in use and the dataguard does not seems to be doing REAL time apply until the current ORL switches.
This is refleted as Pattern1 above.
So if the database has very low activity and the current ORL first and next_time is 3 hours, my A-LAG is reflected as 3 hours.
( support is telling me the issue is cause by surge in log switches - but my stand is that standby has already applied all logs, and should be doing real time apply for the current redo log)