In Data Guard configurations, in case of any disasters in primary database systems or any corruptions or errors in the database that are not recoverable quickly, a failover can be performed manually on the standby database to convert it to a primary database and use it for production services. Another option is to automate the failover using the fast-start failover feature. A fast-start failover can be configured or managed either by DGMGRL or grid control.

If a fast-start failover is not configured and the production database is completely unavailable, and if you want to perform a failover on the standby database in such a case, you first have to understand the status of the standby database, whether all the archived logs or redo has been applied or not. Then you have to perform a failover manually. After the failover, you have to recreate a new standby database. These steps will increase the downtime of the system. Fast-start failover will be invoked automatically if the primary site is unavailable. Also, it'll recover the standby database, perform the failover, and reinstate the old primary database if possible.

Starting from 11g, you can implement a fast-start failover even in the Maximum Performance mode. It supports asynchronous redo transport.

The previously mentioned points can be illustrated in the following diagram:

An observer is required to configure a fast-start failover. It should be configured in a location rather than on the primary and standby databases. It acts as a client and monitors both the primary and standby databases at all times. We must install either the Oracle Client Administrator software or the full Oracle Database software to the observer host.

Based on the FastStartFailoverThreshold value, observer automatically initiates the failover procedure. After performing the failover, the end users will connect to the database again and old connections will be redirected to the new primary database.