FAILOVER

The FAILOVER command invokes a failover that transitions the named (target) standby database into the role of a primary database.

This type of failover is referred to as a manual failover. See Manual Failover for more information.

Note:

Because a failover results in a transition of a standby database to the primary role, it should be performed when the primary database has failed or is unreachable and cannot be recovered in a timely manner. Failover may or may not result in data loss depending on the protection mode in effect at the time of the failover and whether the target standby database was synchronized with the primary database.

Use the SWITCHOVER command if the primary database has not failed and you want the current primary database and a standby database to switch roles with no data loss.

Format

FAILOVER TO <db_unique_name> [IMMEDIATE];

Command Parameters

db_unique_name

The DB_UNIQUE_NAME initialization parameter value of of a physical, logical, or snapshot standby database that you want to fail over to the primary database role.

Usage Notes

  • Always try to perform a complete failover first unless Redo Apply has stopped at the failover target due to an ORA-752 or ORA-600 [3020] error. If one of these errors has occurred, then before proceeding follow the guidelines in "Resolving ORA-752 or ORA-600 [3020] During Standby Recovery" in My Oracle Support Note 1265884.1 at https://support.oracle.com. An immediate failover should only be performed when a complete failover is unsuccessful or in the error case just noted.

  • The specified standby database must be enabled before the primary database fails. However, an enabled standby database that was shut down can be a candidate for the failover operation. In this case, restart the standby database using DGMGRL STARTUP command, then issue the FAILOVER command.

  • The failover operates on the specified standby database and changes its role to a primary database. Bystander standby databases (those not involved in the failover) remain in the standby role.

  • Before you issue the FAILOVER command, verify that you are connected to the standby database that will become the new primary database. If necessary, issue a CONNECT command to connect to the standby database to which you want to failover.

  • If the FAILOVER command is issued without any options, the standby database chosen as the failover target applies all unapplied redo it has received before changing to the primary role. This is referred to as a complete failover.

  • If the broker configuration is operating in maximum protection mode, a manual failover operation will force the protection mode to be maximum performance. The redo transport service settings are unaffected. You need to restore the desired protection mode for the resulting configuration after the failover operation.

    Note:

    With fast-start failover, the broker preserves the protection mode that was in effect prior to the failover.

  • If the FAILOVER command is issued with the IMMEDIATE option, no attempt is made to apply any unapplied redo that has been received. This option more likely results in lost application data even when standby redo log files are configured on the standby database. Additionally, any remaining standby databases in the configuration cannot function as such until they are reinstated or re-created. See Reenabling Disabled Databases After a Role Change for more information.

  • You can perform a manual failover or set up the broker to perform a fast-start failover. See the ENABLE FAST_START FAILOVER command for information about allowing the broker to automatically invoke failover, when conditions warrant a failover.

  • If fast-start failover is enabled, you can perform a complete manual failover only to the fast-start failover target standby database and only if the fast-start failover target standby database is synchronized with, or within the lag limit of, the primary database, and only when the observer is started. You cannot perform an immediate manual failover when fast-start failover is enabled.

  • If Flashback Database was enabled on the former (failed) primary database prior to the failover, the former primary database can be reinstated using the broker's REINSTATE command (see the REINSTATE DATABASE command).

    If failover was performed to a physical standby database, any other physical standby databases that were disabled by the failover can be reinstated if Flashback Database was enabled on the standby database and there are sufficient flashback logs available. See Reenabling Disabled Databases After a Role Change for step-by-step instructions.

  • The original primary database can only participate in the configuration as a standby database after it is reinstated or re-created.

    Caution:

    Shut down the original primary database if it still has any active instances running prior to failing over.

    See Also:

    Reenabling Disabled Databases After a Role Change about reenabling the original primary database so that it could serve as a standby database to the primary database

Command Example

The following example performs a failover in which the standby database, South_Sales, transitions to the primary role: 

DGMGRL> FAILOVER TO 'South_Sales';
Performing failover NOW, please wait...
Failover succeeded, new primary is "South_Sales"

DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
 
  Protection Mode: MaxPerformance
  Members:
    South_Sales - Primary database
    North_Sales - Physical standby database (disabled)
      ORA-16661: The standby database must be be reinstated.
 
Fast-Start Failover: DISABLED
 
Configuration Status:
WARNING