Fast Start Failover (FSFO) is a critical feature of Oracle Data Guard, which is a disaster recovery solution for Oracle databases. It enables quick failover to a standby database in the event of a failure of the primary database. It’s a fully automated process that’s accomplished within seconds or minutes, depending on the specific configuration.
Without Fast Start Failover
- Primary database fails.
- An alert is sent to the DBA team.
- The DBA requests access to the production system, waits until approval, logs in, investigates the error, creates a change request, waits for approval, and finally, initiates the failover.
- This results in a massive delay to RTO.
With FSFO
- The failure of the primary database is automatically detected in the Observer process.
- Automatic failover from primary to the designated standby is initiated. This drastically reduces the RTO and need for hands-on time from the DBA team.
What is the FSFO Observer
Observer is a critical component in an Oracle Data Guard configuration with FSFO enabled.
Role: The Observer is a background process that continuously monitors the primary and standby databases in a Data Guard configuration.
Purpose: Observer helps to automate the failover process in the event of a failure on the primary database, ensuring minimal downtime by promoting the standby database to be the new primary
Location: It’s highly recommended to configure Observer on a separate server from both the primary and standby databases or configure multiple Observer processes on different servers.
Functionality: Observer checks the health of the databases and the network connectivity. If the Observer detects that the primary database is unavailable or not responding, it triggers a failover, switching to the standby database. It also monitors whether the new primary is operating normally after a failover.
Multiple Observers: You can configure multiple Observer process on different servers.
How to Configure Observer and Oracle Data Guard FSFO
Here’s a quick overview on how to configure Observer and FSFO
Environment Details
Site | Ip Address | DB_UNIQUE_NAME |
Primary | XX.XXX.XXX.XXX(N.Virginia) | PERF |
Standby1 | XX.XXX.XXX.XXX (N.Virginia) | PERF_RO1 |
Standby2 | XX.XXX.XXX.XXX (Oregon) | PERF_RO2 |
Standby3 | XX.XXX.XXX.XXX (Oregon) | PERF_RO3 |
Prework/Prechecks before proceeding with configuring Observer and enabling fast failover:
- Primary and all standby sites should be in sync.
- All databases should be added in the dgmgrl configuration.
- Enable flashback "ON" for Primary and all standby sites.
- Standby redo logs on primary and all standby sites + (One extra standby redo group).
- Enable logxptmode to SYNC for primary and all standby sites.
- Change protection mode to MAXAVAILABILITY on the primary site in dgmgrl.
Start Observer on the Primary site (N.Virginia) in the background using this command:
mkdir -p /u01/app/oracle/observer
nohup dgmgrl sys/*******@PERF "start observer file='/u01/app/oracle/observer/First_Observer.dat'" -logfile /u01/app/oracle/observer/First_Observer.log &
Start Observer on the Standby2 site (Oregon) in the background using this command:
nohup dgmgrl sys/******@PERF_RO2 "start observer file='/u01/app/oracle/observer/First_Observer.dat'" -logfile /u01/app/oracle/observer/First_Observer.log &
Two Observers are running, one from N.Virginia and another from Oregon.
Both the Observers are running identically i.e., not Parent/Child or Master/backup.
Requirement
If the Primary (N.Virginia) site is down, then it automatically fails over to Standby1 (N.Virginia). If standby1 (N.Virginia) is not available, then it automatically fails over to Standby2 (Oregon).
disable Fast_start Failover;
edit database 'PERF' set property FastStartFailoverTarget='PERF_RO1,PERF_RO2';
enable fast_start failover;
set masterobserver to <ip address/hostname>
Turning Disaster Recovery into Business Continuity
Fast Start Failover transforms Oracle Data Guard from a reactive disaster recovery tool into a proactive business continuity solution. By automating the failover process, FSFO eliminates the costly delays of manual intervention—reducing recovery time from hours to minutes and keeping your critical business operations running smoothly.
Explore more Oracle resources on Datavail.com.