What is Fast-Start Failover?
In the high-stakes world of Disaster Recovery, every second counts. If your primary database goes down at 3:00 AM, the traditional process is painful: an admin gets paged, wakes up, logs in, verifies the outage, and manually issues the "Failover" command.
By the time the standby takes over, you’ve lost 20 minutes of uptime. Fast-Start Failover (FSFO) is Oracle’s "autopilot" for this nightmare. It allows the database to fail over to the standby automatically, without a single human lifting a finger.
To make an automatic decision safely, FSFO uses a three-way conversation between different components:
The Primary Database: The "Boss" that handles the actual transactions.
The Target Standby: The "Heir" waiting to take over.
The Observer: The "Witness." This is a small, lightweight process (usually running on a separate third site) that constantly talks to both the Primary and the Standby.
The biggest fear in clustering is Split-Brain Syndrome, where both databases think they are the "Primary" and start writing different data. FSFO prevents this using the Observer:
Scenario: The Primary server crashes.
The Check: The Observer notices it can't talk to the Primary. It asks the Standby, "Can you see the Primary?"
The Consensus: If the Standby also says "No," the Observer knows the Primary is truly dead.
The Action: The Observer tells the Standby to become the Primary.
If the Observer can see the Primary but the Standby cannot (e.g., a simple network cut between the two), FSFO will not trigger. This prevents unnecessary failovers.
You can't just flip a switch; FSFO requires a specific environment to be safe:
Data Guard Broker: You must be using the Broker (dgmgrl) to manage your configuration.
Flashback Database: Both the Primary and Standby must have Flashback enabled. This allows the "old" Primary to automatically be reinstated as a Standby once it comes back online.
Protection Mode: It is typically used with Maximum Availability or Maximum Performance (with specific lag limits).
| Benefit | Description |
| Reduced RTO | Your "Recovery Time Objective" drops from minutes (or hours) to seconds. |
| No "Human Error" | Eliminates the risk of a panicked DBA typing the wrong command during an outage. |
| Automatic Reinstatement | When the failed server is fixed and rebooted, FSFO automatically turns it into the new Standby and starts syncing it. |
FSFO is perfect for Mission-Critical applications where even 5 minutes of downtime is unacceptable. However, it requires a very stable network. If your network "flickers" constantly, FSFO might trigger "False Failovers," causing more disruption than it saves.
Once your Observer is running on a separate host, you enable FSFO through the Data Guard Broker:
DGMGRL> ENABLE FAST_START FAILOVER;
You can then check the status to see if the "Witness" (Observer) is watching:
DGMGRL> SHOW CONFIGURATION;
-- Look for "Fast-Start Failover: ENABLED"
Never run the Observer on the same server as your Primary or Standby. If that site loses power, your "Witness" dies along with the database, and the automatic failover will never happen. Always place the Observer at a third geographic location.