| Oracle® Data Guard Broker 10g Release 2 (10.2) Part Number B14230-01 |
|
|
View PDF |
| Oracle® Data Guard Broker 10g Release 2 (10.2) Part Number B14230-01 |
|
|
View PDF |
This chapter describes how the broker manages databases during switchover and failover. This chapter contains the following sections:
An Oracle database operates in one of two roles: primary or standby. Data Guard helps you change the role of a database using either a switchover or a failover:
A switchover is a role reversal between the primary database and one of its standby databases. A switchover guarantees no data loss. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role. The transition occurs without having to reenable either database.
A failover is when the primary database (all instances of a RAC primary database) fails and one of the standby databases is transitioned to take over the primary role. Failover is performed only in the event of a catastrophic failure of the primary database, and 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.
Without the broker, you perform role transitions by first determining if a role transition is necessary and then issuing a series of SQL statements (as described in Oracle Data Guard Concepts and Administration). The broker simplifies switchovers and failovers by allowing you to invoke them using a single key click in Oracle Enterprise Manager or a single command in the DGMGRL command-line interface (referred to in this documentation as manual failover). Moreover, you can enable fast-start failover to fail over automatically when the primary database becomes unavailable. When fast-start failover is enabled, the broker determines if a failover is necessary and initiates the failover to the specified target standby database automatically, with no need for DBA intervention and with no loss of data.
Fast-start failover allows you to increase availability with less need for manual intervention, thereby reducing management costs. Manual failover gives you control over exactly when a failover occurs and to which target standby database. Regardless of the method you choose, the broker coordinates the role transition on all databases in the configuration.
When the database is opened for the first time after a role transition, the DB_ROLE_CHANGE system event fires. You can write a trigger that's associated with this system event to manage tasks after a role change occurs. See the table of system manager events in Oracle Database Application Developer's Guide - Fundamentals for more details.
There are many factors to take into consideration when selecting a standby database to be the next primary database after a switchover or a failover. You need to consider all of the options at the time you are building your Data Guard configuration, including factors such as the characteristics of physical standby databases versus logical standby databases, the network latency to your standby database sites, the computing capabilities at a future primary database site, and so on.
For switchovers, understanding all of the factors can simplify the choice of which standby database to consider as your new primary database. In disaster situations where a failover is necessary, you may be more limited in which standby database is the best one to pick up the failed primary database's activities. The following sections provide guidelines to help you choose a target standby database.
|
Note: For fast-start failover, you must pre-select the target standby database that will be used. Section 5.5 provides more information about fast-start failover. |
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.
|
Note: If the Data Guard configuration is running in maximum protection mode, the broker does not allow a switchover to occur to a logical standby database. |
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.
You can switch a database from the primary role to the standby role, as well as from standby to primary. This is known as a database switchover, because the standby database that you specify becomes the primary database, and the original primary database becomes a standby database. There is no loss of data, the data is consistent between the original primary database and the new primary database after the switchover completes.
Whenever possible, you should switch over to a physical standby database:
If the switchover transitions a physical standby database to the primary role, then:
The original primary database will be switched to a physical standby role.
The online redo log files will be continuously archived from the new primary database to all standby databases in the configuration.
Both the primary database and the target standby database will be restarted as a part of the switchover operation.
Standby databases not involved in the switchover will continue operating in the state they were in before the switchover occurred and will automatically begin applying archived redo log files from the new primary database.
If the switchover transitions a logical standby database to the primary role, then:
The original primary database will be switched to a logical standby role.
Neither the primary database nor the logical standby database needs to be restarted after the switchover completes.
Other logical standby databases in the broker configuration that were not involved in the switchover will remain viable after the switchover. There is no need to restart any databases.
Switchover to a logical standby database is disallowed when the configuration is running in maximum protection mode.
|
Warning: Switching over to a logical standby database results in the physical standby databases in the broker configuration being disabled by the broker, making these databases no longer viable as standby databases. Section 5.4.2 describes how to restore their viability as standby databases. |
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.2.
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.
Once you start the switchover, the broker:
Verifies that the primary and the target standby databases are in the following states:
The primary database is enabled and is in the ONLINE state.
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.
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.
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.
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.
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.
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.
You can convert a standby database to a primary database when the original primary database fails and there is no possibility of recovering the primary database in a timely manner. This is known as a manual failover. There may or may not be data loss depending upon whether your primary and target standby databases were transactionally consistent at the time of the primary database failure. The word manual is used to contrast this type of failover with a fast-start failover (described in Section 5.5).
This section contains the following topics to help you perform manual failovers:
|
Note: You can perform a manual failover even if fast-start failover is enabled. See Section 5.5.2.4 for more information. |
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, 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.2.
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.2.
During a complete failover, the broker controls the failover steps described in Section 5.4.1.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.2 describes how to do this. During an immediate failover, the broker controls the failover steps described in Section 5.4.1.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. |
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;
|
See Also: "Scenario 8: Performing a Manual Failover Operation" in Chapter 7 and the reference information for the FAILOVER command in Chapter 8 |
If the standby database you want to fail over to the primary role 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 reset to the maximum performance mode unless fast-start failover is enabled.
|
Note: When fast-start failover is enabled, a manual failover can only be performed to the pre-selected target standby database.If you perform a manual failover when fast-start failover is enabled, the broker preserves the protection mode at the same maximum availability level in which it was operating before the failover occurred. |
Redo transport settings (SYNC, ASYNC, or ARCH) on the other standby databases not involved in the failover do not change. You can subsequently upgrade the protection mode as described in Section 4.6.1.
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.2 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.
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.
Once you start a complete failover, the broker:
Checks to see if the primary database is still available and, if so, issues a warning message asking whether you want to continue with the failover operation. If you are using Enterprise Manager and choose to continue, the primary database is shut down.
Verifies that the target standby database is enabled. If the database is not enabled, you will not be able to perform a failover to this database. If the target is a RAC standby database, the broker shuts down all instances except the apply instance.
Waits for the target standby database to finish applying any remaining archived redo log files before stopping Redo Apply or SQL Apply.
Transitions the target standby database into the primary role, opens the new primary database in read/write mode, determines whether or not any standby databases that did not participate in the failover operation have applied redo data beyond the new primary database and thus need to be reenabled, and starts redo transport services to begin transmitting redo data to all standby databases not involved in the failover and not required to be reenabled.
If a standby database not involved in the failover is not disabled by the broker during this failover, it will remain in the state it was in before the failover. For example, if a physical standby database was operating in read-only mode, it will remain in read-only mode.
If the target is a RAC standby database, the broker restarts instances that it shut down prior to the failover.
The broker allows the failover to proceed as long as there are no errors for the standby database that you selected to participate in the failover. Errors occurring for any standby databases not involved in the failover will not stop the failover. If you initiated a complete failover and it fails, you might need to retry the failover as an immediate failover.
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.
Once you start an immediate failover, the broker:
Verifies that the target standby database is enabled. If the standby database is not enabled for management by the broker, then the failover cannot occur.
Stops Redo Apply or SQL Apply on the standby database immediately, without waiting until all available redo data has been applied. This may result in data loss.
Transitions the target standby database into the primary role, opens the new primary database in read/write mode, and starts redo transport services.
After an immediate failover completes to a physical standby database, all the standby databases in the configuration, regardless of their type, are disabled. They must be reenabled before they can serve as standby database to the new primary database. See Section 5.4.2 for information.
The broker allows the failover to proceed as long as there are no errors for the standby database that you selected to participate in the failover.
To maintain a viable disaster-recovery solution after failover you may need to perform additional steps to reenable disabled databases to protect your data in the event of another disaster. Similarly, after a switchover to a logical standby database you must reenable any physical standby databases that were disabled prior to reenabling them to restore your original disaster-recovery solution.
The act of reenabling or reinstating a disabled database refers to the concept of performing a procedure to successfully reenable a disabled database.
Use either of the following procedures to re-enable a database that was disabled due to a switchover or failover operation:
Reinstate the database using the DGMGRL REINSTATE DATABASE command or the reinstate option in Enterprise Manager.
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
Reenable the standby database from a copy of the primary database.
The procedures for reenabling a standby database are documented in Oracle Data Guard Concepts and Administration.
If a database must be reenabled 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
Whether you reinstate or reenable 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 re-enable 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.
Table 5-1 Re-Enabling Disabled Databases After Failover or Switchover
The following sections describe how to reinstate or reenable a database.
You can use the broker's REINSTATE command to reenable the failed primary database after performing a complete failover to either a physical or logical standby database. You can also use the broker's REINSTATE command to reenable any physical standby databases that were not the target of the failover operation but were disabled during a complete failover to a physical standby database.
Databases that can be reinstated will have the following status value:
ORA-16661: the standby database needs to be reinstated
For the REINSTATE command to succeed, Flashback Database must have been enabled on the database prior to the failover and there must be sufficient flashback logs on that database. In addition, the database to be reinstated and the new primary database must have network connectivity.
To reinstate a database:
Restart the database to the mounted state
Connect to the new primary database
Use Enterprise Manager or DGMGRL to reinstate the database
When reinstating a failed primary database, the broker reenables it as a standby database of the same type (physical or logical standby database) as the old standby database. When reinstating physical standby databases that were disabled during a failover, the broker reenables them as physical standby databases to the new primary database.
Reinstatement Using Enterprise Manager
On the Data Guard Overview page, click the Database must be reinstated link. This brings up the General Properties page that provides a Reinstate button. After you click the Reinstate button, Enterprise Manager begins reinstating the database.
When the process is complete, the database will be enabled as a standby database to the new primary database, and Enterprise Manager displays the Data Guard Overview page.
Issue the following command while connected to any database in the broker configuration, except the database that is to be reinstated:
DGMGRL> REINSTATE DATABASE db_unique_name;
The newly reinstated standby database will begin serving as standby database to the new primary database. If the database is not reinstated successfully, then you must reenable it from a copy of the new primary database, as described in Section 5.4.2.2.
If you performed a failover or switchover that requires you to reenable the failed primary database or standby databases that were disabled during the role transition, follow the procedures in Oracle Data Guard Concepts and Administration.
After the database has been reenabled, enable broker management of the reenabled standby database by using the DGMGRL ENABLE DATABASE command.
Fast-start failover allows the broker to automatically fail over to a previously chosen, synchronized standby database in the event of loss of the primary database. Fast-start failover quickly and reliably fails over the target standby database to the primary database role, without requiring you to perform any manual steps to invoke the failover. Fast-start failover can be used only in a broker configuration and can be configured only through DGMGRL or Enterprise Manager.
This section describes how to enable fast-start failover and an observer site that monitors the fast-start failover environment. The observer is a separate OCI client-side component that runs on a different computer from the primary and standby databases and monitors the availability of the primary database. The observer is described in more detail in Section 5.5.6.
Once the observer is enabled, no further user interaction is required. If both the observer and the standby database lose connectivity to the primary database, the observer waits for the amount of time specified by the FastStartFailoverThreshold property before initiating a fast-start failover. Moreover, after the failover completes, the former primary database is automatically reinstated as a standby database in the new broker configuration when a connection to it is reestablished.
Figure 5-1 shows the relationships between the primary database, target standby database, and the observer during fast-start failover:
Before Fast-Start Failover: Data Guard is operating in a steady state, with the primary database transmitting redo data to the target standby database and the observer monitoring the state of the entire configuration.
FastStartFailover Ensues: Disaster strikes the primary database and its network connections to both the observer and the target standby database are lost. Upon detecting the break in communication, the observer attempts to reestablish a connection with the primary database for the amount of time defined by the FastStartFailoverThreshold property before initiating a fast-start failover. If the observer is unable to regain a connection to the primary database within the specified time, and the target standby database is ready for fast-start failover, then fast-start failover ensues.
After Fast-Start Failover: The fast-start failover has completed and the target standby database is running in the primary database role. After the former primary database has been repaired, the observer reestablishes its connection to that database and reinstates it as a new standby database. The new primary database starts transmitting redo data to the new standby database.
Figure 5-1 Relationship of Primary and Standby Databases and the Observer
The following sections describe these topics:
Viewing Fast-Start Failover Configuration Statistics and Status
Reinstating the Former Primary Database in the Broker Configuration
Shutting Down Databases In a Fast-Start Failover Environment
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.
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 theFastStartFailoverTarget 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.
|
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.
|
See Also: "ENABLE FAST_START FAILOVER" in Chapter 8 and Section 7.6, "Scenario 5: Enabling Fast-Start Failover and the Observer" for examples |
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.
|
Note: Administration at the target standby site should be as comprehensive as that at the primary site because the standby database may assume the primary role without prior notice. Staff support, hardware and software, security (both software and site), network connections, and bandwidth should be equivalent at both sites. |
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?
Shutting Down the Primary Database When Fast-Start Failover Is Enabled
Performing Manual Role Changes When Fast-Start Failover Is Enabled
Once you enable fast-start failover and start the observer, the observer continuously monitors the environment to ensure the primary database is available. This section lists the steps the observer takes to determine if fast-start failover is needed and then performs one, if necessary.
Step 1 Monitor the environment to ensure the primary database is available.
The following list describes some of the conditions with the primary database, system, or site that could cause the observer to attempt a fast-start failover:
Broken network connection between the observer and the primary database
If the connection is lost between the observer and the primary database, or there are network failures that cause the primary database to be isolated, the observer attempts a fast-start failover.
If a single-instance primary database (either RAC or nonRAC), or if all instances of a RAC primary database fail, the observer attempts a fast-start failover.
If a single-instance primary database (either RAC or nonRAC), or if all instances of a RAC primary database are shut down with the ABORT option, the observer attempts a fast-start failover. Fast-start failover will not be attempted for the other types of database shutdown (NORMAL, IMMEDIATE, TRANSACTIONAL).
If the observer determines that one or more datafiles in the primary database have been taken offline by the database because of I/O errors, the observer attempts a fast-start failover.
Except for the last condition (Offline datafiles), the observer attempts to reconnect to the primary database within the time specified by the FastStartFailoverThreshold configuration property before attempting a fast-start failover. When the primary database datafiles are offline, the observer initiates a fast-start failover immediately, without waiting for the amount of time specified by the FastStartFailoverThreshold property to expire.
Step 2 Reconnect within the time specified by FastStartFailoverThreshold.
If the observer detects a problem, the observer attempts to reconnect to the primary database within the time specified by the FastStartFailoverThreshold property. The FastStartFailoverThreshold time interval starts when the observer first detects there might be a failure with the primary database.
If the primary database is a Real Application Clusters (RAC) database, the observer will attempt to connect to the remaining primary instances. Fast-start failover will not occur unless all instances comprising the RAC primary database are perceived to have failed.
|
Note: If the observer determines that the data files on the primary database are offline but the primary system is running, fast-start failover is initiated immediately without waiting for theFastStartFailoverThreshold interval to expire. |
Step 3 Verify the target standby database is ready for failover.
If the primary database is still unavailable when the FastStartFailoverThreshold expires, the observer verifies the target standby database is ready to fail over to the primary database role.
Fast-start failover cannot occur if:
Fast-start failover is no longer enabled
The observer cannot connect to the target standby database
The observer and the target standby database are inconsistent with regard to the current state of the broker configuration
The observer was stopped, and when it restarted, only the standby database was available
The target standby database was not synchronized with the primary database at the time the primary database failed
The target standby database, if it is a logical standby database, is still loading its copy of the former primary database's dictionary (in this case the FS_FAILOVER_STATUS column in the V$DATABASE view contains LOADING DICTIONARY instead of READY)
The network connection exists between the target standby database and the primary database
The FS_FAILOVER_STATUS column in the V$DATABASE view for the target standby database displays a reason why fast-start failover cannot occur
A manual failover is already in progress. See Section 5.4 for complete information about manual failovers.
The primary database was shut down intentionally, in a controlled fashion
Step 4 Initiate a fast-start failover.
If the target standby database is ready for failover, the observer immediately invokes a fast-start failover. The observer will fail over the target standby database to the primary database role. If failover is not possible for some reason, the observer will try again to connect to the primary database indefinitely.
Step 5 Reinstate the former primary database as a new standby database.
After the fast-start failover completes successfully, the observer will attempt to reinstate the former primary database as a new standby database when a connection to the former primary database is reestablished.
When fast-start failover is enabled, you cannot:
Change:
The configuration protection mode to either maximum protection or maximum performance
The LogXptMode property on the primary or target standby databases
The FastStartFailoverTarget property on the primary or target standby databases
Disable or delete:
The broker configuration
The standby database that is the target of fast-start failover
Perform a manual failover:
Unless the conditions listed in Section 5.5.2.4 have been met
To a standby database that is not configured as the fast-start failover target
To a standby database that is not synchronized with the primary database, even if it is configured as the target standby database
To determine if the configuration is ready for fast-start failover to occur, issue the DGMGRL SHOW CONFIGURATION command (as shown in Section 5.5.3), or query the V$DATABASE view on either the primary and target standby databases. Fast-start failover is possible if the FS_FAILOVER_STATUS column displays SYNCHRONIZED value and the FS_FAILOVER_OBSERVER_PRESENT column displays YES for the target standby database.
Perform a switchover to the target standby database unless the standby database is synchronized with the primary database and the observer is running
Attempt to open the primary database from another Oracle client (for example, with the SQL*Plus SQL> STARTUP command). Doing so will result in the following error begin returned:
ORA-16649: database will open after Data Guard broker has evaluated Fast-Start Failover status
This error occurs because, when fast-start failover is enabled, the broker must perform additional validity checks before allowing the database to open and allowing transactions to commit.
Fast-start failover will not be triggered if the primary or standby database is shut down normally (using SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL). A normal shutdown will prevent fast-start failover until the primary database and standby database are connected and communicating again.
If fast-start failover is enabled you can still perform a switchover or a manual failover as long as the following conditions are met:
The role change is directed to the same standby database that was specified with the FastStartFailoverTarget property
The target standby database is synchronized with the primary database
For manual failover, the observer is started and communicating with the target standby database
|
See Also: Section 5.3 and Section 5.4 for more information about switchovers and manual failovers, respectively |
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:
Table 5-2 FS_FAILOVER_STATUS Column of the V$DATABASE View
| Column Value | Description | Fast-Start Failover ... |
|---|---|---|
DISABLED |
Fast-start failover is disabled. | Is not possible |
BYSTANDER |
Fast-start failover is enabled, but this standby database is not the target of the fast-start failover. The database cannot provide fast-start failover status information. | Is enabled |
SYNCHRONIZED |
The primary and target standby databases are synchronized. | Is possible if the target standby database displays SYNCHRONIZED and the FS_FAILOVER_OBSERVER_PRESENT column displays YES |
UNSYNCHRONIZED |
The target standby database does not have all of the primary database redo data. | Is not possible |
LOADING DICTIONARY |
Displays only on a logical standby database that has not yet completed loading a copy of the primary database's data dictionary. | Is not possible |
SUSPENDED |
Displays only on the target standby database when either the primary or target standby database was shut down in a controlled fashion (using the NORMAL, IMMEDIATE, or TRANSACTIONAL, options, but not the ABORT option). Fast-start failover is inhibited in the SUSPENDED state. It is cleared upon reconnection to the primary database. |
Is not possible |
STALLED |
Displays on the primary database after loss of connectivity to the target standby database and the change to the UNSYNCHRONIZED state cannot be confirmed by either the target standby database or the observer.
It stalls because it is likely a failover has occurred. Note: this state also occurs during startup when fast-start failover is synchronized and neither the target standby database nor the observer are present to confirm it is okay to continue opening the database. The primary database will not stall upon loss of connectivity to the target standby database if both the primary and standby databases lost connectivity to the observer more than a minute in the past. Fast-start failover is not possible in this case to allow the primary database to continue committing redo even though neither the target standby database nor the observer are present. |
Is possible |
PRIMARY UNOBSERVED |
Displays only on the target standby database when it is SYNCHRONIZED with the primary database, has connectivity to the observer, but the primary database does not have a connection to the observer. This is a rare state. |
Is not possible |
REINSTATE REQUIRED |
The failed primary database requires reinstatement as a new standby database to the new primary. The observer automatically starts the reinstatement process. REINSTATE REQUIRED is present only after fast-start failover has occurred and shows only on the new primary database. |
Has completed |
REINSTATE IN PROGRESS |
Reinstatement of the failed primary database as a new standby database is in progress. | Has completed |
REINSTATE FAILED |
Reinstatement of the failed primary database as a new standby database failed. See Section 10.1 for details about the broker's drc* log files. |
Has completed |
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.
|
Note: Disabling fast-start failover does not stop the observer. To stop the observer, see Section 5.5.6.4, "Stopping the Observer". |
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 theDISABLE 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.
|
Note: Setting theDG_BROKER_START initialization parameter to FALSE implicitly disables 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/
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
The following sections provide information about managing the observer:
The observer should be installed and run on a computer system that is separate from the primary and standby systems. Installing and starting the observer is an integral part of enabling fast-start failover and is described in detail in these sections:
Section 2.1 describes installing Oracle Database Enterprise Edition or Oracle Personal Edition on the observer system.
Section 5.5.2 describes how to start the observer as a part of the step-by-step process to enable fast-start failover. Examples for starting the observer through Oracle Enterprise Manager and DGMGRL are included in Section 6.4 and Section 7.6, respectively.
There can be only one observer monitoring the broker configuration. If you attempt to start another one, the broker returns the following error message:
ORA-16647: could not start more than one observer
To start the observer, you must be able to login to DGMGRL as SYS. The observer is an OCI client that connects to the primary and target standby databases using the same SYS credentials you used when you connected to the Data Guard configuration with DGMGRL.
You can find information about the observer by querying the following columns in the V$DATABASE view:
FS_FAILOVER_OBSERVER_HOST shows the name of the computer on which the observer is running
FS_FAILOVER_OBSERVER_PRESENT shows whether or not the observer is connected to the local database
Table 5-3 FS_FAILOVER_OBSERVER_PRESENT Column of the V$DATABASE View
| Column ValueFoot 1 | Description |
|---|---|
YES |
Observer is currently connected to the local database |
NO |
Observer is not connected to the local database |
YES.For example, to determine if fast-start failover can occur, the FS_FAILOVER_STATUS column displays SYNCHRONIZED and the FS_FAILOVER_OBSERVER_PRESENT column displays YES for the target standby database. For example:
| Database | FS_FAILOVER_STATUS |
FS_FAILOVER_OBSERVER_PRESENT |
|---|---|---|
| Primary | SYNCHRONIZED |
YES |
| Standby | SYNCHRONIZED |
YES |
In the following example, assume the network between the primary database and the observer has failed. In this case, the FS_FAILOVER_STATUS and FS_FAILOVER_OBSERVER_PRESENT columns will appear as shown in the following table and fast-start failover will not occur:
| Database | FS_FAILOVER_STATUS |
FS_FAILOVER_OBSERVER_PRESENT |
|---|---|---|
| Primary | SYNCHRONIZED |
NO |
| Standby | PRIMARY UNOBSERVED |
YES |
If the primary and target standby databases stay connected but the connection to the observer is lost, then the broker reports that the configuration is not observed. The configuration and database status report that the observer is not running and return the following status messages:
ORA_16658: unobserved Fast-Start Failover configuration ORA-16820: Fast-Start Failover observer is no longer observing this database
While the configuration is in the unobserved state, fast-start failover cannot happen. Therefore, the primary database can continue processing transactions, even if the target standby database fails. The configuration status returns the SUCCESS status after the observer reestablishes its connection to the primary database, which then notifies the target standby database.
You may want to stop the observer when you no longer want to use fast-start failover (see Section 5.5.4, "Disabling Fast-Start Failover") or if you want to move the observer to a different host machine (see Section 5.5.6.5, "Moving the Observer to Another Computer").
To stop the observer when fast-start failover is enabled, the primary database and target standby database must be connected and communicating with each other. Stopping the observer does not disable the fast-start failover. However, fast-start failover cannot occur when the primary database is in the unobserved state.
To stop the observer when fast-start failover is not enabled, only the primary database must be running.You can stop the observer while connected to any database in the broker configuration, as follows:
Using Enterprise Manager
Choose the Stop Observer option on the first page of the fast-start failover wizard and click Continue at the bottom of the page. See the Enterprise Manager online help system for more information.
Using DGMGRL
Issue the following command:
DGMGRL> STOP OBSERVER;
See the STOP OBSERVER command for more information.
|
Note: The observer does not stop immediately when you issueSTOP OBSERVER command. When the broker receives the STOP OBSERVER request, it informs the observer the next time the observer contacts the broker. |
To move the observer to another computer:
Stop the observer from any computer system in the broker configuration, as described in Section 5.5.6.4.
Start the observer on the new computer system, as described in Step 5 of Section 5.5.2.
There is no need to disable fast-start failover when you move the observer.
The observer persistently maintains information about the fast-start failover configuration in a binary file created in the working directory where you started the observer. By default, the observer creates this file when it is started and names the file fsfo.dat. This file contains connect descriptors to both the primary and the target standby databases. Ensure this file cannot be read by unauthorized users.
Once the file is created, you cannot change its name and location. However, you can change the name or the location of the file if you use the DGMGRL START OBSERVER command and include the FILE qualifier. See the START OBSERVER command for more information.
|
Note: If the observer is stopped abnormally (for example, by typingCTRL/C), restart it and reference the existing fsfo.dat file with the FILE qualifier. |
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.2.
Reinstatement is supported only after failover in a broker configuration. It also requires Flashback Database to be enabled on both the primary and target standby databases. Section 5.5.1 provides complete information about all of the fast-start failover and reinstatement requirements.
The broker cannot automatically reinstate the former primary database if:
Another failover or switchover occurred after the fast-start failover completed but before the former primary database restarted.
Fast-start failover was disabled.
The observer cannot connect to the former primary database.
The former primary database cannot connect to the new primary database.
The former primary database and the new primary database are not configured in the same fast-start failover environment.
The former primary database was disabled because of a manual failover, not a fast-start failover.
|
Note: Standby databases that are disabled during switchover, manual failover, or fast-start failover cannot be automatically reinstated. |
If automatic reinstatement fails, the broker will log errors and the former primary database will remain in the mounted state. At this point, you can either:
Disable fast-start failover (described in Section 5.5.4) and attempt to open the former primary database.
Manually reinstate the former primary database, as described in Section 5.4.2.
If a failure occurs once a reinstatement operation (automatic or manual) is underway, the broker logs the appropriate information in the broker configuration files and log files. The former primary database is disabled. Most in-progress failures cannot be restarted (for example, archived redo log file corruption on the primary database). You must reenable the database as a standby database manually, as described in Oracle Data Guard Concepts and Administration.
Perform the following steps if you need to shut down the primary or standby databases:
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.
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.
