Scenario 10: Performing a Manual Failover Operation

You invoke a failover operation in response to an emergency situation, usually when the primary database cannot be accessed or is unavailable.

See Choosing a Target Standby Database before you fail over to decide which standby database should be the target of the failover. The following scenario describes a failover to the remote database called South_Sales.

Note:

If multiple fast-start failover targets are configured, then a manual failover is only possible to the current fast-start failover target.

If you want to perform a manual failover to a standby database that is not the fast-start failover target standby database, you must first disable fast-start failover using the FORCE option on the standby database you want to fail over. See Disabling Fast-Start Failover for more information about the FORCE option.

1. (Optional) Check the readiness of the target standby.

   To validate the target standby database to ensure that it's ready to become the new primary database, use the VALIDATE DATABASE command, as shown in the following example:

   DGMGRL>  VALIDATE DATABASE 'South_Sales';
   
     Database Role:     Physical standby database
     Primary Database:  North_Sales
       Warning: primary database was not reachable
   
     Ready for Switchover:  No
     Ready for Failover:    Yes (Primary Not Running)
   
     Flashback Database Status:
       Database     Status           Retention Target
       North_Sales  Unknown          Unknown
       South_Sales  On               1440   
   
     Managed by Clusterware:
       North_Sales:  Unknown        
       South_Sales:  NO             
       The static connect identifier allows for a connection to database "North_Sales".
   
     Temporary Tablespace File Information:
       North_Sales TEMP Files:  Unknown
       South_Sales TEMP Files:  3
   
     Data file Online Move in Progress:
       North_Sales:  Unknown
       South_Sales:  No
   
     Transport-Related Information:
       Transport On:  No
       Gap Status:    Unknown
       Transport Lag:  0 seconds (computed 59 seconds ago)
       Transport Status:  Success
   
     Log Files Cleared:
       North_Sales Standby Redo Log Files:  Unknown
       South_Sales Online Redo Log Files:   Unknown
       South_Sales Standby Redo Log Files:  Unknown
   

2. To perform the failover operation, you must connect to the standby database to which you want to fail over as a user that has the SYSDG or SYSDBA privilege. For example:

   DGMGRL> CONNECT sys@South_Salesm;
   Password: password
   Connected to "South_Sales"
   Connected as SYSDBA.
   

3. Now you can issue the failover command to make the target standby database the new primary database for the configuration.

   DGMGRL> FAILOVER TO 'South_Sales';
   2022-12-20T00:11:12.329+00:00
   Performing failover NOW, please wait...
   
   2022-12-20T00:11:18.332+00:00
   Failover succeeded, new primary is "South_Sales".
   
   2022-12-20T00:11:18.333+00:00
   Failover processing complete, broker ready.
   

   Note that after the failover completes, the original primary database cannot be used as a standby database of the new primary database unless it is reinstated or re-created (as described in Reenabling Disabled Databases After a Role Change).

4. Issue the SHOW CONFIGURATION command to verify the failover.

   DGMGRL> SHOW CONFIGURATION;
   
   Configuration - DRSolution
   
     Protection Mode: MaxAvailability
     Members:
     South_Sales - Primary database
       Warning: ORA-16627: No member available to support the protection mode.
   
       North_Sales - Physical standby database (disabled)
         ORA-16661: The standby database must be reinstated.
   
   Fast-Start Failover:  Disabled
   
   Configuration Status:
   WARNING   (status updated 11 seconds ago)
   

   Note that in this example the configuration was operating in maximum availability mode. The protection mode was preserved after the failover, but the configuration now has a warning status indicating that no configuration member is available to support this mode. The former primary database is disabled and must be reinstated or replaced with a new standby database before the configuration can operate in maximum protection mode again.

5. Show the new primary database.

   DDGMGRL> SHOW DATABASE 'South_Sales';
   
   Database - South_Sales
   
     Role:                PRIMARY
     Intended State:      TRANSPORT-ON
     Redo Rate:           86.30 KByte/s  in 16 seconds (computed 13 seconds ago) 
     Instance(s):
       SouthSales
   
     Database Warning(s):
       ORA-16627: No member available to support the protection mode.
   
   Database Status:
   WARNING
   6.
   DGMGRL> SHOW DATABASE 'North_Sales';
   
   Database - North_Sales
   
     Role:                PHYSICAL STANDBY
     Intended State:      APPLY-ON
     Transport Lag:       (unknown)
     Apply Lag:           (unknown)
     Average Apply Rate:  (unknown)
     Real Time Query:     OFF
     Instance(s):
       NorthSales
   
   Database Status:
   DISABLED - ORA-16661: The standby database must be reinstated.
   
   

6. Issue the SHOW DATABASE command to see that the former (failed) primary database was disabled by the broker as a consequence of the failover. It must be reinstated (as described in Reenabling Disabled Databases After a Role Change).

   DGMGRL> SHOW DATABASE 'North_Sales';
   Database - North_Sales
    
     Role: PHYSICAL STANDBY
     Intended State: APPLY-ON
     Transport Lag: (unknown)
     Apply Lag: (unknown)
     Apply Rate: (unknown)
     Real Time Query: OFF
     Instance(s):
       north_sales1
    
   Database Status:
   ORA-16661: the standby database must be be reinstated