Really appreciate your efforts. Your way of explaining concepts are top notch. Very patiently you cover every point. Very much informative for fresher DBAs and those who really want to understand each and every small details. Being experienced DBA , i watched complete video and did not feel to fast forward to finish it. Very interesting.
Thanks for the suggestion. Yes, performance tuning is in my To-Do list but before that I have to cover the RAC. The reason is, while explaining the performance tuning concepts, I have to refer to RAC and single instance both.
Great explanation on the Data Guard architecture! However, I have a question regarding the Managed Recovery Process (MRP) and its role in Real-Time Apply: Does the MRP always apply changes directly from the redo log buffer in a real-time fashion? There seems to be a general belief that it's the archived logs that are being applied to the standby database. Or is it that the archived logs are only applied during a 'Gap Resolution Scenario' when there are missing redo records? I'm trying to clarify this specific aspect of how Data Guard operates. Thanks in advance for shedding light on this
Hi @joseluisdelarosa728 - thanks for watching my video and providing your feedback. Actually MRP does not read from redo log buffers. In real time apply, it reads from the SRLs and apply to the standby DB. If it not real-time apply, then it reads from the archived logs in the standby. Your remaining understanding is correct and yes it is a general belief that it's the archived logs that are being applied to the standby database but in a real time apply configuration, the archived logs are applied only in a situation when the primary is generating a very huge redo data very fast causing the redo logs in primary (and the SRLs in standby) to switch and archive even before the MRP is able to read and write that to the standby DB. In that case the MRP has no option other than to go and read the archived logs for the changes it was not able to keep up the speed with.
Thank you so much for your detailed explanation and for taking the time to clarify my doubts. I really appreciate the depth of knowledge you've shared, and it has enhanced my understanding of the Data Guard's real-time apply mechanism. Your videos are incredibly helpful and educational.
Really appreciate your efforts. Your way of explaining concepts are top notch. Very patiently you cover every point.
Very much informative for fresher DBAs and those who really want to understand each and every small details. Being experienced DBA , i watched complete video and did not feel to fast forward to finish it. Very interesting.
I appreciate your feedback with the nice words. I'm happy to hear that you found the video useful and interesting.
I would request you to make some videos on Performance tuning as well for us please. Really want to learn critical concepts from you.
Thanks for the suggestion. Yes, performance tuning is in my To-Do list but before that I have to cover the RAC. The reason is, while explaining the performance tuning concepts, I have to refer to RAC and single instance both.
Great explanation on the Data Guard architecture! However, I have a question regarding the Managed Recovery Process (MRP) and its role in Real-Time Apply:
Does the MRP always apply changes directly from the redo log buffer in a real-time fashion? There seems to be a general belief that it's the
archived logs that are being applied to the standby database. Or is it that the archived logs are only applied during a 'Gap Resolution Scenario'
when there are missing redo records? I'm trying to clarify this specific aspect of how Data Guard operates. Thanks in advance for shedding light on this
Hi @joseluisdelarosa728 - thanks for watching my video and providing your feedback.
Actually MRP does not read from redo log buffers. In real time apply, it reads from the SRLs and apply to the standby DB. If it not real-time apply, then it reads from the archived logs in the standby.
Your remaining understanding is correct and yes it is a general belief that it's the archived logs that are being applied to the standby database but in a real time apply configuration, the archived logs are applied only in a situation when the primary is generating a very huge redo data very fast causing the redo logs in primary (and the SRLs in standby) to switch and archive even before the MRP is able to read and write that to the standby DB. In that case the MRP has no option other than to go and read the archived logs for the changes it was not able to keep up the speed with.
Thank you so much for your detailed explanation and for taking the time to clarify my doubts.
I really appreciate the depth of knowledge you've shared, and it has enhanced my understanding
of the Data Guard's real-time apply mechanism. Your videos are incredibly helpful and educational.
@@joseluisdelarosa728 - Glad that it helped.