Would appreciate if you can clarify, why does the documentation say the below: Once fast-start failover is enabled, the broker will ensure that fast-start failover is only possible when the configured data loss guarantee can be upheld. If the configured data loss guarantee cannot be upheld, redo generation on the primary database will be stalled. In maximum availability and maximum performance modes, to avoid a prolonged stall, either the observer or target standby database may allow the primary database to continue redo generation after first recording that a fast-start failover cannot happen. So it appears as if primary will be stalled for a split second while its being recorded that a fast-start failover cannot happen. Am I reading it right? Thanks!
Thank you! Indeed brilliant video. I posted the above comment before going through the video. Now I have gone through the the part "Deep Dive: Fast-Start Failover Maximum Performance mode". It clears a lot of questions that were running in my mind. However I can still not understand why stall (the primary) at all? After 3 seconds, if the observer is anyways going to give permission to continue, then why stall at all?
I have a question and am not able to find any answer no matter where I check. So the scenario is we have two oracle servers with DataGuard synchronizing one(SECONDARY) from other (PRIMARY) with no Fast Start Failover. The network had some problem and the connectivity has lost. The PRIMARY will still remain as PRIMARY and manually we have started up the second one as PRIMARY as well since it will not see any PRIMARY (I assume that is possible, please let me know if it is not) Then what will happen when the connection is restored, is it possible to have some kind of configuration on DataGuard to tell one particular DB will remain as PRIMARY and the other one will stop ?
Great content. However, I think there is a mistake at 51:47 when the slide posits that "The primary never commits without the observer quorum". Does that hold true when the standby catches up with the primary, but the observer status remains unsynchronized?
Brilliant video! Very professional delivery and presentation. Very insightful content that will save a huge amount of research effort. Is there another online content or resources I can keep an eye on as I embark on a big FSFO project? many thanks.
Appreciate the explanation. My only feedback is to stop playing too much with the mouse. It distracts the viewer by lot and not helping anything. Other than that, solid content!
Thanks for the feedback. As you might infer from my accent, I'm Italian, and I am urged to move my hands when talking. 🤣 I'll make sure to keep it in mind for future recordings.
![[LIVE] : ONE ลุมพินี 91 | คู่เอก "คมอาวุธ vs อเล็กเซย์"](http://i.ytimg.com/vi/V0RkEfYFsgM/mqdefault.jpg)
Would appreciate if you can clarify, why does the documentation say the below:
Once fast-start failover is enabled, the broker will ensure that fast-start failover is only possible when the configured data loss guarantee can be upheld. If the configured data loss guarantee cannot be upheld, redo generation on the primary database will be stalled. In maximum availability and maximum performance modes, to avoid a prolonged stall, either the observer or target standby database may allow the primary database to continue redo generation after first recording that a fast-start failover cannot happen.
So it appears as if primary will be stalled for a split second while its being recorded that a fast-start failover cannot happen. Am I reading it right?
Thanks!
Thank you! Indeed brilliant video. I posted the above comment before going through the video. Now I have gone through the the part "Deep Dive: Fast-Start Failover Maximum Performance mode". It clears a lot of questions that were running in my mind. However I can still not understand why stall (the primary) at all? After 3 seconds, if the observer is anyways going to give permission to continue, then why stall at all?
I have a question and am not able to find any answer no matter where I check. So the scenario is we have two oracle servers with DataGuard synchronizing one(SECONDARY) from other (PRIMARY) with no Fast Start Failover. The network had some problem and the connectivity has lost. The PRIMARY will still remain as PRIMARY and manually we have started up the second one as PRIMARY as well since it will not see any PRIMARY (I assume that is possible, please let me know if it is not) Then what will happen when the connection is restored, is it possible to have some kind of configuration on DataGuard to tell one particular DB will remain as PRIMARY and the other one will stop ?
Great content. However, I think there is a mistake at 51:47 when the slide posits that "The primary never commits without the observer quorum". Does that hold true when the standby catches up with the primary, but the observer status remains unsynchronized?
Good catch. The intention of that subtitle was: "The primary never commits without the observer quorum IF THE STANDBY IS NOT REACHABLE"
@@ludodba Nice. Learned a ton from this video. Thank you.
Brilliant video! Very professional delivery and presentation. Very insightful content that will save a huge amount of research effort. Is there another online content or resources I can keep an eye on as I embark on a big FSFO project? many thanks.
This content is amazing but remembering info is a challenge for me, also could you please help me with a road map to be a good dba from scratch
Remembering info: Take notes and keep them organized! And practice as much as you can.
Does Fast start failover require Active data guard?
no, it's included in Oracle Data Guard (Enterprise Edition license)
Appreciate the explanation. My only feedback is to stop playing too much with the mouse. It distracts the viewer by lot and not helping anything. Other than that, solid content!
Thanks for the feedback. As you might infer from my accent, I'm Italian, and I am urged to move my hands when talking. 🤣
I'll make sure to keep it in mind for future recordings.