ENABLE FAST_START FAILOVER
Enables the broker to fail over to a specifically-chosen, synchronized standby database in the event of loss of the primary database, without requiring you to perform any manual steps to invoke the failover. See Section 5.5.2, "Enabling Fast-Start Failover" for complete information.
■ The prerequisites described in Section 5.5.1 must be met before you issue this command to enable fast-start failover.
■ Issuing the ENABLE FAST_START FAILOVER command does not trigger a failover, it only allows the observer to monitor the configuration and initiate fast-start failover if conditions warrant a failover.
■ You can enable fast-start failover while connected to any database system in the broker configuration.
■ If you do not start the observer after you have enabled fast-start failover, the ORA-16819 warning displays for the primary and target standby databases. For example: Intended State: ONLINE Instance(s):
sales1
Current status for "North_Sales":
Warning: ORA-16819: Fast-Start Failover observer not started
■ To enable fast-start failover for a broker configuration with multiple standby databases, the FastStartFailoverTarget property on the primary database and one standby database must be set to point to each other. Both the primary database and the target standby database must have:
– Standby redo logs configured
– The LogXptMode property set to SYNC
– Flashback Database enabled on both the primary and standby databases In addition, the configuration protection mode must be set to MAXAVAILABILITY.
Step 2 in Section 5.5.2 and Section 9.2.9 provide more information about the FastStartFailoverTarget property.
Once you have enabled fast-start failover, you must comply with the restrictions
ENABLE FAST_START FAILOVER
Command Example
Example 1
The following example enables fast-start failover.
DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.
Example 2
The following example attempts to enable fast-start failover when the configuration protection mode is MAXPERFORMANCE.
DGMGRL> SHOW CONFIGURATION;
Configuration
Name: The SUPER cluster Enabled: YES
Protection Mode: MaxPerformance Fast-Start Failover: DISABLED Databases:
dgb1 - Primary database
dgb12 - Physical standby database Current status for "The SUPER cluster":
SUCCESS
DGMGRL> ENABLE FAST_START FAILOVER;
Error: ORA-16651: requirements not met for enabling Fast-Start Failover Failed.
EXIT
EXIT
Exits (quits) the command-line interface.
Format
EXIT;
Command Parameters
None.
Usage Notes
■ This command has the same effect as the QUIT command.
■ A database connection is not required to execute this command. However, if you are connected, this command breaks the connection.
Command Example
Example 1
The following example demonstrates how to exit (quit) the command-line interface.
DGMGRL> EXIT;
FAILOVER
FAILOVER
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 manual failover. See
Section 5.4, "Manual Failover" for more information.
Format
FAILOVER TO database-name [ IMMEDIATE ];
Command Parameters
database-name
The name of the standby database you want to fail over to the primary database role.
Usage Notes
■ 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 may perform a complete manual failover only to the target standby database and only if the target standby database is
synchronized with the primary database, and only when the observer is started.
You cannot perform an immediate manual failover when fast-start failover is enabled.
■ The specified standby database must be enabled before the primary database fails.
However, an enabled standby database that was taken offline 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 one its role to a primary database. Any other standby databases 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.
Note: Because a failover results in a transition of a standby database to the primary role, it should be performed only in the event of a catastrophic failure of the primary database when there is no possibility of recovering the primary database 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 you want the current primary database and a standby database to switch roles with no data loss.
FAILOVER
■ If the FAILOVER command is issued without any options, the standby database chosen as the failover target applies all unpiled redo it has received before changing to the primary role.
■ If the standby database that you want to fail over to the primary role is a RAC database, the broker will shut down all of the instances except the apply instance before it continues the failover operation. See Section 5.4.3 for details.
■ If the standby database that is transitioning into the role of primary database is a physical standby database, then the database instance (or instances) will be restarted if the database was opened read-only prior to the failover. The database restart occurs as part of the failover. If the database is a logical standby database, the database instance (or instances) does not need to be restarted. Failing over to a logical standby database has the side effect of disabling all other standby
databases in the configuration.
■ If the broker configuration is in either MAXPROTECTION or MAXAVAILABILITY protection mode, a manual failover operation will force the protection mode to be MAXPERFORMANCE. The redo transport service settings are unaffected. You need to restore the desired protection mode for the resulting configuration after the failover operation.
■ 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 reenabled. See Section 5.4.3 for more information about reenabling databases.
■ 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 on page 8-33).
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 Section 5.4.3, "Reenabling Disabled Databases After Failover or Switchover" for step-by-step instructions.
■ The original primary database can only participate in the configuration as a standby database after it is reenabled.
Note: With fast-start failover, the broker preserves the protection mode at the same maximum availability level in which it was operating before the failover.
Caution: You should shut down the original primary database if it still has any active instances running prior to failing over.
See Also: Section 5.4.3 about reenabling the original primary database so that it could serve as a standby database to the primary database
FAILOVER
Command Examples
Example 1
The following example performs a failover in which the standby database, DR_Sales, transitions to the primary role:
DGMGRL> FAILOVER TO "DR_Sales";
Performing failover NOW, please wait...
Operation requires shutdown of instance "dr_sales1" on database "DR_Sales"
Shutting down instance "dr_sales1"...
ORA-01109: database not open Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "dr_sales1" on database "DR_Sales"
Starting instance "dr_sales1"...
ORACLE instance started.
Database mounted.
Failover succeeded, new primary is "DR_Sales"
HELP
HELP
Displays online help for the Data Guard command-line interface.
Format
HELP [topic];
Command Parameter
topic
The topic for which you want to display help information. If you do not specify a topic, the command lists all of the topics and the format. Valid topics are:
ADD CONNECT CREATE DISABLE EDIT ENABLE EXIT FAILOVER HELP QUIT REINSTATE REM
REMOVE SHOW SHUTDOWN START STARTUP STOP
SWITCHOVER