Failover is initiated when a serious problem exists on the primary database, making it inaccessible. This problem generally arises from hardware or software errors on the server or storage layer; also, a disaster may cause complete or partial loss of services. In such cases, we can convert a standby database role to primary by performing failover and continue providing it with production database service. Performing a Data Guard failover operation for production purposes is a serious consideration and needs a lot of caution. The following considerations are important in this context:
- Failover decision must be taken with regard to the service Recovery Time Objective (RTO) value.
- The standby database hardware must be powerful enough to sustain production load.
- Multiple standby databases are recommended; this is so that data protection continues after a failover operation.
- If the flashback database is not enabled on the primary database, after a failover it's not possible to include the old primary database into the Data Guard configuration again. This means we'll have to restore the database on the primary side. If flashback is enabled, it's possible to reinstate the failed primary database without a full restore operation. The following diagram explains the failover process:
Before performing failover, ensure that all the available redo is being applied on the standby database for minimum data loss. Remember that it's also possible to guarantee a zero data loss failover by using the Maximum Protection mode. Also note that once the failover process is finished, the new primary database will be started in Maximum Performance mode even though your previous Data Guard protection mode is either Maximum Protection or Maximum Availability.
Failover can be performed manually with SQL*Plus, the Data Guard broker, Cloud Control, or automatically using the Fast Start failover with an observer. In automatic failover, the observer will monitor the state of the primary database and all the standby databases of the Data Guard configuration. Whenever the primary database is not accessible, the observer will wait according to the predefined parameter FastStartFailoverThreshold and then perform the failover to the standby database.
As stated before, if the flashback database is enabled and the standby database role is changed to primary by FSFO and if the observer reestablishes the connection to the failed primary database as well as reinstates it as a new standby database, the new primary database starts sending redo to the new standby database.