5 Switchover and Failover Operations

5.2.1 Choosing a Target Standby Database for Switchover

When performing a switchover in a configuration whose standby databases are all of the same type (all physical or all logical standby databases), choose the standby database that has the least amount of unapplied redo. By choosing the standby database with the least amount of unapplied redo, you can minimize the overall time it takes to complete the switchover operation. For example:

• Using DGMGRL, you can do this by examining the RecvQEntries monitorable property of each standby database in the configuration. For example, connect to one of the standby databases in the configuration and issue the SHOW DATABASE database_name RecvQEntries command. (When real-time apply is enabled and keeping up, this property will return no rows.)

• Using Enterprise Manager, you can view the value of the ApplyLag column for each standby database in the Standby Databases section of the Data Guard Overview Page.

If the configuration contains both physical and logical standby databases, consider choosing a physical standby database (that has the least amount of unapplied redo) to be the target standby database. A switchover to a physical standby database is preferable because all databases in the configuration will be available as standby databases to the new primary database after the switchover operation completes. Whereas a switchover to a logical standby database will invalidate and disable the physical standby databases in the configuration. You will then need to reenable the physical standby databases from a backup of the new primary database before you can reenable them.

5.2.2 Choosing a Target Standby Database for Failover

When performing a failover in a configuration that contains all physical standby databases or all logical standby databases, choose the standby database that has the most data archived to it. By choosing the standby database that has the most amount of redo data archived to it, you can minimize the amount of data loss and in some cases, incur no data loss at all.

If the configuration contains both physical and logical standby databases, consider choosing a physical standby database as the target standby database. A failover to a physical standby database is preferable because it is likely that all standby databases in the configuration will still be available as standby databases to the new primary database after the failover operation completes. A failover to a logical standby database requires that all other standby databases be reenabled from a copy of the new primary database after the failover completes. In addition, a logical standby database may contain only a subset of the data present in the primary database. (For example, if the DBMS_LOGSTDBY.SKIP procedure was used to specify which database operations done on the primary database will not be applied to the logical standby database.)

However, there may be exceptions to the recommendation to choose a physical standby database as the target standby database. For example, if the physical standby database is lagging behind the logical standby database (the physical standby database was in read-only mode or running with a log apply delay via the DelayMins property) and your business requires minimum downtime, consider selecting the logical standby database as the failover target.

5.3.1 Before You Perform a Switchover Operation

Consider the following points before you begin a switchover:

• When you start a switchover, the broker verifies that at least one standby database, including the primary database that is about to be transitioned to the standby role, is configured to support the overall protection mode (maximum protection, maximum availability, or maximum performance).

• Prepare the primary database in advance for its possible future role as a standby database in the context of the overall protection mode (see Section 4.6). Such preparation includes:

  • Ensuring that standby redo log files are configured on the primary database if you intend to use SYNC or ASYNC redo transport service to the database after the switchover.

  • Presetting redo transport services related properties, such as LogXptMode, NetTimeout, StandbyArchiveLocation, and AlternateLocation. For more details about managing redo transport services using configurable properties, see Section 4.4.

  • Presetting log apply services related properties, such as DelayMins and ApplyParallel. For more details about managing log apply services using configurable properties, see Section 4.5.

  • For each temporary table, verifying that temporary files associated with that table on the primary database also exist on the standby database. See Oracle Data Guard Concepts and Administration for more information about temporary files.

  Note that the broker does not use the properties to set up redo transport services and log apply services until you actually switch over the primary database to the standby role. Thus, the validity of the values of these properties is not verified until after the switchover. Once you set these properties, their values persist through role changes during switchover and failover.

• If fast-start failover is enabled, a switchover can be performed only to the pre-specified target standby database and only if the standby database is synchronized with the primary database. For information about enabling fast-start failover and starting the observer, see Section 5.5.2.

After a switchover completes, the broker preserves the overall Data Guard protection mode as part of the switchover process by keeping the protection mode at the same protection level (maximum protection, maximum availability, or maximum performance) it was at before the switchover. Also, the network transmission mode (SYNC, ASYNC, or ARCH) for transporting redo to other standby databases not involved in the switchover does not change after a switchover. Log apply services on all other standby databases not involved in the switchover automatically begin applying archived redo log files from the new primary database.

If there are both logical and physical standby databases in the configuration and the switchover occurs to a logical standby database, you need to reenable all physical standby databases, as described in Section 5.4.3.

5.3.2 Starting a Switchover

The act of switching roles should be a well-planned activity. The primary and standby databases involved in the switchover should have as small a transactional lag as possible. Oracle Data Guard Concepts and Administration provides information about setting up the databases in preparation of a switchover.

To start a switchover using Enterprise Manager, select the standby database that you want to change to the primary role and click Switchover. When using DGMGRL, you need to issue only one SWITCHOVER command to specify the name of the standby database that you want to change into the primary role.

The broker controls the rest of the switchover, as described in Section 5.3.3.

5.3.3 How the Broker Performs a Switchover

Once you start the switchover, the broker:

1. Verifies that the primary and the target standby databases are in the following states:

   1. The primary database is enabled and is in the ONLINE state.

   2. The participating standby database is enabled and is in the ONLINE state.

   The broker allows the switchover to proceed as long as there are no errors for the primary database and the standby database that you selected to participate in the switchover operation. Errors occurring for any other standby databases not involved in the switchover will not impede the switchover.

2. Shuts down all instances except one.

   If the primary database is a RAC database, the broker keeps only one instance running and shuts down all other instances before it continues the switchover. If the standby database you want to switch to the primary role is a RAC database, the broker shuts down all instances except the apply instance before it continues the switchover. If those other instances cannot be shut down, the switchover fails. In this case, you must manually shut down those other instances and issue the switchover command again. It is also important that you do not start any new instances during the switchover. If you must manually shut down the instances on the standby database, do not shut down the apply instance.

3. Switches roles between the primary and standby databases.

   The broker first converts the original primary database to run in the standby role. Then, the broker transitions the target standby database to the primary role. If any errors occur during either conversion, the broker stops the switchover. See Section 10.3, "Troubleshooting Problems During a Switchover Operation" for more information.

4. Updates the broker configuration file to record the change in roles.

   Because the configuration file profiles all database objects in the configuration, this ensures that each database will run in the correct role should it be restarted later for any reason.

5. Restarts the new standby (former primary) database if the switchover occurs with a physical standby database, and Redo Apply begins applying redo data from the new primary database. If this is a RAC database, the broker restarts the instances that it shut down prior to the switchover.

6. Restarts the new primary database if it was a physical standby database, opens it in read/write mode, and starts redo transport services transmitting redo data to the standby databases, including to the former primary database. If the switchover occurs to a logical standby database, there is no need to restart any databases. If this is a RAC database, the broker restarts the instances that it shut down prior to the switchover.

The broker verifies the state and status of the databases to ensure that the switchover transitioned the databases to their new role correctly. Standby databases not involved in the switchover and not disabled by the broker after the switchover will continue operating in the state they were in before the switchover. For example, if a physical standby database was in read-only mode, it will remain in that mode after switchover completes. Redo Apply and SQL Apply on all other standby databases not involved in the switchover automatically begin applying archived redo log files from the new primary database.

5.4.1 Complete and Immediate Manual Failovers

Using Enterprise Manager or DGMGRL, you can perform either a complete (recommended) or an immediate failover:

• A complete failover is the recommended and default failover option. It automatically recovers the maximum amount of data for the protection mode of the original primary database application data. A complete failover also attempts to bring along any standby databases not involved in the failover, to continue serving as standby databases to the new primary database.

  The behavior of a complete failover varies depending on the type of standby database being used:

  • After failover to a physical standby database, the original primary database must be reenabled to act as a standby database for the new primary database. In addition, some standby databases may be disabled by the broker during the failover if the broker detects that they have applied redo beyond where the new primary database had applied. Any database that was disabled by the broker must be reenabled using the steps described in Section 5.4.3.

  • After failover to a logical standby database, the original primary database and all standby databases in the configuration (that were not the target of the failover) will be disabled and must be reenabled to act as standby databases for the new primary database. Any database that was disabled by the broker must be reenabled using the steps described in Section 5.4.3.

  During a complete failover, the broker controls the failover steps described in Section 5.4.2.1.

• An immediate failover is the fastest type of failover. However, no additional data is applied on the standby database once you invoke the failover. Another consequence of immediate failover is that you must also reenable the original primary database and all other standby databases not involved in the failover before they can serve as standby databases to the new primary database. Section 5.4.3 describes how to do this. During an immediate failover, the broker controls the failover steps described in Section 5.4.2.2.

  Caution:

  Always try to perform a complete failover first. Only when a complete failover is unsuccessful should you perform an immediate failover. Depending on the destination attributes of redo transport services, a complete failover can occur without any data loss, while an immediate failover usually results in data loss.

5.4.2 Performing a Manual Failover Operation

After determining that there is no possibility of recovering the primary database in a timely manner, ensure that the primary database is shut down and then begin the failover operation.

The steps in this section describe how to perform a manual failover. Depending on the failover and the types of standby databases involved, some of the databases may need to be restarted or reenabled. The instructions guide you through the appropriate steps for each type of situation.

Step 1   Determine which of the available standby databases is the best target for the failover.

Follow the guidelines described in Section 5.2, "Choosing a Target Standby Database".

Step 2   Start the failover.

Using Enterprise Manager or DGMGRL, perform either a complete (recommended) or an immediate failover.

Manual Failover Using Enterprise Manager:

On the Data Guard Overview Page in Enterprise Manager, select the standby database that you want to change to the primary role and click Failover. Then, on the Failover Confirmation Page, click Yes to invoke the default Complete failover option.

Manual Failover Using DGMGRL:

On the target standby database, issue the FAILOVER command to invoke a complete failover, specifying the name of the standby database that you want to change into the primary role:

DGMGRL> FAILOVER TO database-name;

If the target standby database is a RAC database, the broker will shut down all instances except the apply instance before it continues the failover. If the broker cannot shut down the instances, the failover fails. In this case, you must manually shut down all instances except the apply instance and issue the FAILOVER command again. It is also important that you do not start any new instances during the failover. The broker restarts instances that it shut down prior to the failover.

Step 3   Reset the protection mode.

After a manual failover (complete or immediate), the overall Data Guard protection mode is handled as follows:

• If the protection mode was at maximum protection, it is reset to maximum performance. You can upgrade the protection mode later, if necessary, as described in Section 4.6.1.

• If the protection mode was at maximum availability, it remains at maximum availability.

Redo transport settings (SYNC, ASYNC, or ARCH) on standby databases other than the target standby database do not change.

Step 4   Re-establish a disaster-recovery configuration.

To maintain a viable disaster-recovery solution in the event of another disaster, you may need to perform the additional steps described in Section 5.4.3 to:

• Reinstate the original primary database to act as a standby database in the new configuration.

• Flash back (or reinstate) standby databases in the configuration that were disabled by the broker.

  After a complete failover finishes, any standby database not involved in the failover that is not viable as a standby for the new primary database will be disabled by the broker. This can happen for either of these reasons:

  • The broker detects that the standby database has applied redo data beyond what has been applied on the new primary database.

    For instance, this could happen if a standby database not involved in the failover has applied more log files than the new primary database itself has applied. The standby database must be reenabled or flashed back before it can serve as a standby for the new primary database.

  • The failover was to a logical standby database, the broker disables all of the (physical and logical) standby databases in the configuration that were not involved in the failover. They must be reenabled before they can serve as standby to the new primary database.

5.4.3 Reenabling Disabled Databases After Failover or Switchover

To restore your original disaster-recovery solution after switchover to a logical standby database or after failover to any standby database, you may need to perform additional steps.

Databases that have been disabled after a role transition are not removed from the broker configuration, but they are disabled in the sense that the databases are no longer managed by the broker.

To reenable broker management of these databases, you must reinstate or re-create the databases using one of the following procedures:

• If a database can be reinstated, the database will show the following status after a complete failover:

  ORA-16661: the standby database needs to be reinstated
  
  

  Reinstate the database using the DGMGRL REINSTATE DATABASE command or the reinstate option in Enterprise Manager, as described in Section 5.4.3.1, "How to Reinstate a Database".

• If a database must be re-created from a copy of the new primary database, it will have the following status:

  ORA-16795: the broker detects that database re-creation is required
  
  

  Re-create the standby database from a copy of the primary database and then reenable it. The procedures for creating a standby database are documented in Oracle Data Guard Concepts and Administration. See Section 5.4.3.2, "How to Re-create and Reenable a Disabled Database" for more information.

Whether you reinstate or re-create a database depends on if you performed a switchover or failover and on the type of standby database that was the target of the operation.

The following table describes how to reenable disabled databases based on the type of role transition that was performed. The status value associated with databases that are disabled after a switchover or failover will also guide you in choosing which procedure to use. These status values can be viewed in the output from the DGMGRL SHOW DATABASE or on the Data Guard Overview page in Enterprise Manager.

The following sections describe how to reinstate or reenable a database.

ORA-16661: the standby database needs to be reinstated

DGMGRL> REINSTATE DATABASE db_unique_name;

5.5.1 Prerequisites for Enabling Fast-Start Failover

The following prerequisites must be met before the broker allows you to enable fast-start failover:

• Ensure the broker configuration is running in maximum availability mode.

  See Section 4.6.1 for information about configuring the protection mode, standby redo logs, and the LogXptMode property.

• Enable Flashback Database and set up a flash recovery area on both the primary database and the target standby database.

  See Oracle Database Backup and Recovery Advanced User's Guide) and "Setting Up Flash Recovery Areas as Destinations" in Oracle Data Guard Concepts and Administration.

• Install the DGMGRL command-line interface on the observer computer as described in Section 2.1.

• Configure the TNSNAMES.ORA file on the observer system so that the observer is able to connect to the primary database and the pre-selected target standby database.

5.5.2 Enabling Fast-Start Failover

You can enable fast-start failover from any site, including the observer site, while connected to any database in the broker configuration. Enabling fast-start failover does not trigger a failover. Instead, it allows the observer to begin observing the primary and standby databases and initiate a fast-start failover should conditions warrant a failover.

Perform the following steps to enable fast-start failover and start the observer. The steps assume that you are connected as SYS and that a primary and standby database are already set up in a broker configuration.

Step 1   Determine which of the available standby databases is the best target for the failover.

Follow the guidelines described in Section 5.2, "Choosing a Target Standby Database".

Step 2   Specify the target standby database with the FastStartFailoverTarget property.

When configuring fast-start failover, the FastStartFailoverTarget property on the current primary database, you can specify only one standby database:

• If there is only one standby database in the configuration, you can skip this step and continue with Step 3. The broker will automatically set the FastStartFailoverTarget property on the primary and standby databases to point to each other as their respective target during a failover.

• If there is more than one standby database in the configuration, you must explicitly set the FastStartFailoverTarget property on the primary database and target standby database to point to each other for the purpose of defining which standby database will be the target of a fast-start failover. For example:

  DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget = 'DR_Sales';
  DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY FastStartFailoverTarget = 'North_Sales';
  
  

  In this example, the current primary database, North_Sales, specifies DR_Sales as its failover target, and the target standby database, DR_Sales, specifies the current primary database as its target. When DR_Sales becomes the primary database it must have a standby target to which it can fail over.

  Note:

  To change the FastStartFailoverTarget property to point to a different standby database, disable fast-start failover, set the FastStartFailoverTarget property, and restart fast-start failover.

See Section 9.2.9, "FastStartFailoverTarget" for more information about this property.

Step 3   Set the FastStartFailoverThreshold property.

Fast-start failover will occur if both the observer and the target standby database lose connection to the primary database for the period of time specified by the FastStartFailoverThreshold property.

Set the FastStartFailoverThreshold property to specify the number of seconds you want the observer and target standby database to wait (after detecting the primary database is unavailable) before initiating a failover. For example:

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;

This is a configuration-level property and the setting of this property holds for the duration that fast-start failover is enabled. The default value for the FastStartFailoverThreshold property is 30 seconds. If you have a RAC primary database, consider specifying a higher value to minimize the possibility of a false failover in the event of an instance failure.

The time interval starts when the observer first loses its connection to the primary database. If the observer is unable to regain a connection to the primary database within the specified time, then the observer begins a fast-start failover provided the standby database is ready to fail over. Although the default value of 30 seconds is typically adequate for detecting outages and failures on most configurations, you can adjust failover sensitivity with this property to decrease the probability of false failovers in a temporarily unstable environment.

Step 4   Enable fast-start failover.

Use Enterprise Manager Fast-Start Failover wizard or the DGMGRL ENABLE FAST_START FAILOVER command to enable fast-start failover. To enable fast-start failover, both the primary and target standby databases must be running and have connectivity, and satisfy all of the prerequisite conditions listed in Section 5.5.1.

Enable Fast-Start Failover Using Enterprise Manager

To enable fast-start failover in Enterprise Manager, use the Fast-Start Failover wizard. On the Data Guard Overview Page next to the "Fast-Start Failover" status field, click Disabled to invoke the Fast-Start Failover Page. Then, on the Fast-Start Failover Change Mode Page, click Enabled. The broker will start the observer and change the configuration's protection mode to maximum availability, if necessary. Then, on the Fast-Start Failover Configure Page, select the standby database that should be the target of a failover. See Section 5.2, "Choosing a Target Standby Database" for helpful advice.

1. See Also:

   Section 6.4, "Scenario 4: Enabling Fast-Start Failover and the Observer" for an example of the fast-start failover wizard

Enable Fast-Start Failover Using DGMGRL

To enable fast-start failover with DGMGRL, issue the ENABLE FAST_START FAILOVER command while connected to any database system in the broker configuration, including on the observer computer. For example:

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

If there is only one standby database in the broker configuration, the broker will automatically set the FastStartFailoverTarget property for both the primary and standby databases when fast-start failover is enabled.

Step 5   Start the Observer.

To start the observer, only the primary database must be running; it is not necessary for the target standby database to be running.

You can start the observer before or after you enable fast-start failover. However, it is recommended that you have the observer running whenever you have fast-start failover enabled. If fast-start failover is enabled, the observer immediately begins monitoring the status and connections to the primary and target standby databases.

Starting the Observer Using Enterprise Manager

If the Enterprise Manager agent is installed on the observer computer, it automatically starts the observer when you enable fast-start failover through Enterprise Manager. If the agent is not present, you must start the observer manually using the following instructions for the DGMGRL command-line interface.

Starting the Observer Using DGMGRL

To start the observer with DGMGRL, issue the following command on the observer computer:

DGMGRL> START OBSERVER;

The observer is a continuous, foreground process; thus, the command-line prompt on the observer computer does not return until you issue the STOP OBSERVER command from another DGMGRL session. To issue commands and interact with the broker configuration, you must connect through another DGMGRL client session.

See the START OBSERVER command for more information.

Step 6   Verify the fast-start failover environment.

To verify the readiness of the fast-start failover configuration, issue the DGMGRL SHOW CONFIGURATION VERBOSE command on the primary database. For example:

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration
 Name:                DRSolution
 Enabled:             YES
 Protection Mode:     MaxAvailability
 Fast-Start Failover: ENABLED
 Databases:
   North_Sales - Primary database
   DR_Sales    - Physical standby database
               - Fast-Start Failover target
Fast-Start Failover
 Threshold: 45 seconds
 Observer:  observer.foo.com
Current status for "DRSolution":
SUCCESS 

The following sections provide more information about the fast-start failover environment:

• What Happens When Fast-Start Failover and the Observer Are Running?

• Restrictions When Fast-Start Failover is Enabled

• Shutting Down the Primary Database When Fast-Start Failover Is Enabled

• Performing Manual Role Changes When Fast-Start Failover Is Enabled

5.5.3 Viewing Fast-Start Failover Configuration Statistics and Status

You can query the V$DATABASE view to verify the observer is started and the configuration is ready for fast-start failover. For example, to verify the observer is started and the configuration is ready for fast-start failover, query the V$DATABASE view on the target standby database or issue the SHOW CONFIGURATION VERBOSE command.

The following example shows the fast-start failover information for the DRSolution configuration:

DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration
 Name:                DRSolution
 Enabled:             YES Protection Mode:     MaxAvailability
 Fast-Start Failover: ENABLED
 Databases:
   North_Sales - Primary database
   DR_Sales    - Physical standby database
               - Fast-Start Failover target
Fast-Start Failover
 Threshold: 45 seconds
 Observer:  observer.foo.com

Current status for "DRSolution":
SUCCESS 

When querying the V$DATABASE view, pay special attention to the FS_FAILOVER_STATUS column that can contain the values described in Table 5-2:

5.5.4 Disabling Fast-Start Failover

Disabling fast-start failover prevents the observer from initiating a failover to the target standby database. In this case, manual failover may still be possible. See Section 5.4 for information about manual failover.

To disable fast-start failover, use the Fast-Start Failover wizard in Enterprise Manager or the DGMGRL DISABLE FAST_START FAILOVER [FORCE] command. The FORCE option disables fast-start failover on the database to which you are connected even when errors occur. Whether or not you use the FORCE option depends on if the primary and target standby database have network connectivity:

• If the primary and target standby database have network connectivity, Oracle recommends that you use DISABLE FAST_START FAILOVER without the FORCE option. This method will disable fast-start failover on all databases in the broker configuration.

  If errors occur during the disable operation, the broker returns an error message and stops the disable operation.

• If the primary and target standby databases do not have network connectivity or if the database to which you are connected does not have network connectivity with the primary database, consider using DISABLE FAST_START FAILOVER with the FORCE option.

  The broker may not be able to disable fast-start failover on all databases in the broker configuration when you issue the DISABLE FAST_START FAILOVER FORCE command. As a result, there is no guarantee that the observer will not perform a fast-start failover to the target standby database if the observer determines that conditions warrant a failover. The following list indicates the extent to which fast-start failover is disabled in the broker configuration when the DISABLE FAST_START FAILOVER FORCE command is issued on the primary database, target standby database, and a standby database that is not the fast-start failover target.

  If you issue this command on:

  • The primary database, the primary database attempts to disable fast-start failover on as many databases in the configuration with which it has a network connection. If the primary database does not have connectivity with the target standby database, fast-start failover remains enabled on the target standby database and the observer may still attempt a fast-start failover if conditions warrant a failover.

    Caution:

    This action may result in two databases in the configuration simultaneously assuming the primary database role should fast-start failover occur.

  • The target standby database when it does not have connectivity with the primary database, fast-start failover is disabled only on the target standby database. In this case, the observer cannot perform a fast-start failover even if conditions warrant a failover. Disabling fast-start failover with the FORCE option when connected to the target standby database is the only method that guarantees fast-start failover will not occur.

    If the primary database and the target standby database regain network connectivity, the broker will disable fast-start failover for the entire broker configuration.

  • Another standby database that does not have connectivity with the primary database, fast-start failover is disabled for this database. Because fast-start failover was not disabled on the target standby database, the observer may still attempt a fast-start failover to the target standby database should conditions warrant a failover.

    Caution:

    When you are experiencing network disconnections and you issue the DISABLE FAST_START FAILOVER FORCE command on the primary database or a standby database that does not have connectivity with the primary database, fast-start failover may not be disabled for all databases in the broker configuration. As a result the observer may still initiate fast-start failover to the target standby database, if conditions warrant a failover. This may result in two databases in the configuration simultaneously assuming the primary database role.

Conditions Requiring the FORCE Option

Disabling fast-start failover without the FORCE option can succeed only if the database on which the command is issued has a network connection with the primary database and if the primary database and target standby database have a network connection. This is the recommended method for disabling fast-start failover.

However, there may be situations in which you must disable fast-start failover when the primary database and the target standby database do not have a network connection, or the database on which you issued the disable fast-start failover command does not have a network connection to the primary database. In cases where there is a lost network connection, be aware that the observer may attempt a fast-start failover to the target standby database if conditions warrant a failover.The FORCE option may be the preferred method for disabling fast-start failover when:

• A network outage isolates the primary database from the observer and the target standby database, while the databases are synchronized.

  In this case, the primary database stalls and prevents any further transactions from committing because a fast-start failover may have occurred while it was isolated. If you expect the network to be disconnected for a long time, disable fast-start failover with the FORCE option on the primary database to allow processing to continue (without waiting for the connection to the target standby database or the observer computer to be restored).If possible, confirm that fast-start failover has not occurred to the target standby database prior to disabling fast-start failover with the FORCE option on the primary database.

  Caution:

  This action may result in two databases in the configuration simultaneously assuming the primary database role.

• You want to conduct a manual failover to any standby database in the configuration (for example, because a failure occurred on the primary database at a time when the primary and target standby database were not synchronized).

  In this case fast-start failover cannot occur because the databases are not synchronized. You cannot perform a manual failover to the target standby database for the same reason. To proceed, you must first disable fast-start failover using the FORCE option, and then perform a manual failover.

  Caution:

  This action will result in loss of data and the possibility of two databases in the configuration simultaneously assuming the primary database role.

• A fast-start failover to the target standby database fails.

  If the failover fails for any reason, it could leave the target standby database inoperable, regardless of whether the target standby database is synchronized. If there is another standby database that is available for failover, you can perform a manual failover to that standby database after you first disable fast-start failover using the FORCE option on that standby database.

• You want to prevent fast-start failover from occurring because the primary database will resume service soon.

  In this case, disable fast-start failover using the FORCE option on the target standby database. Once the primary database regains connectivity with the target standby database, fast-start failover will be disabled for all the databases in the configuration.

Disabling Fast-Start Failover Using Enterprise Manager

Click Disable in the Fast-Start Failover wizard. Then, click Continue to proceed to the next page. See the Enterprise Manager online Help system for more information.

Disabling Fast-Start Failover Using DGMGRL

Issue the DISABLE FAST_START FAILOVER command or the DISABLE FAST_START FAILOVER FORCE command. See the "DISABLE FAST_START FAILOVER" command in Chapter 8 for more information.

5.5.5 Performance Considerations for Fast-Start Failover

Consider the following recommendations to obtain better performance when using fast-start failover:

• Fast-start failover can be faster when the target of the failover is a logical standby database.

  This is because a logical standby database does not need to be restarted nor opened (it is already open) to assume the primary role. A physical standby database always needs to be opened, and may need to be restarted if it has been opened read-only since the last time it restarted.

• The failover time is dependent upon whether the target standby database (physical or logical standby database) has applied all of the redo data it has received from the primary database.

• Fast-start failover is faster when you take steps to optimize recovery so that the application of redo data to the standby database is kept up to date with the primary database's rate of redo application. To optimize the log apply rate:

  • Do not configure the DelayMins property to delay applying archived redo log files to the standby database (see Section 4.5 for more information)

  • See "Tuning the Log Apply Rate for a Physical Standby Database" in Oracle Data Guard Concepts and Administration

  • See the Oracle Maximum Availability Architecture white papers at:

    http://otn.oracle.com/deploy/availability/
    

5.5.6 Managing the Observer

The observer is integrated in the DGMGRL client-side component and runs on a different computer from the primary or standby databases and from the computer where you manage the broker configuration. The observer continuously monitors the fast-start failover environment to ensure the primary database is available (described in Section 5.5.2.1). The observer's main purpose is to enhance high availability and lights out computing by reducing the human intervention required by the manual failover process that can add minutes or hours to downtime.

You can manage the observer through either the Data Guard Overview pages in Oracle Enterprise Manager or using DGMGRL commands. Figure 5-2 shows how the observer monitoring a fast-start failover configuration.

Figure 5-2 The Observer in the Fast-Start Failover Environment

Description of "Figure 5-2 The Observer in the Fast-Start Failover Environment"

The following sections provide information about managing the observer:

• Installing and Starting the Observer

• Viewing Information About the Observer

• What Happens if the Observer Fails?

• Stopping the Observer

• Moving the Observer to Another Computer

• How the Observer Maintains Fast-Start Failover Configuration Information

ORA-16647: could not start more than one observer

ORA_16658: unobserved Fast-Start Failover configuration
ORA-16820: Fast-Start Failover observer is no longer observing this database

5.5.7 Reinstating the Former Primary Database in the Broker Configuration

After a fast-start failover completes successfully, the observer automatically attempts to reinstate the former primary database as a standby database. Reinstatement restores high availability to the broker configuration so that, in the event of a failure of the new primary database, another fast-start failover can occur. The reinstated database can act as the fast-start failover target for the new primary database, making a subsequent fast-start failover possible. The new standby database is a viable target of a failover when it begins applying redo data received from the new primary database.

The broker can reinstate the former primary database as a standby database without the need to reenable the primary database or manually performing the Flashback Database operation. To reinstate the former primary database, the database must be started and mounted, but it cannot be opened. The broker reinstates the database as a standby database of the same type as the former standby database.

If the former primary database cannot be reinstated automatically, you can manually reinstate it using either the DGMGRL REINSTATE command or Enterprise Manager. Step-by-step instructions for manual reinstatement are described in Section 5.4.3.

5.5.8 Shutting Down Databases In a Fast-Start Failover Environment

Perform the following steps if you need to shut down the primary or standby databases:

1. Shut down the observer and wait for the FS_FAILOVER_OBSERVER_PRESENT column in the V$DATABASE fixed view to contain the value "NO" for both the primary and target standby databases.

2. Shut down the primary database and the target standby database using either DGMGRL SHUTDOWN command or the SQL*Plus SHUTDOWN statement.

When restarting the databases, you may restart them in any order. When both databases have been restarted, you may restart the observer.