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:
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.