This is called failover. Fast-start failover can incur data-loss within the time specified by FastStartFailoverlagLimit. Don't initiate failover unless at least 30 minutes of history is available. Any unsent redo data residing on the far sync instance is transmitted to the target physical standby prior to converting the physical standby into a primary database. On Linux/Unix, the directory specified by the DG_ADMIN environment Database services can be configured to be active in specific database roles on Oracle RAC databases and on single-instance databases managed by Oracle Restart. Depending on the failover and the types of standby databases involved, some of the databases may need to be reinstated or re-created. This can be compared to performing an RMAN restore of the datafiles from a backup taken prior to the specified SCN, but is much faster. The time interval specified by the FastStartFailoverThreshold property is ignored if the master observer detects that a user-configurable condition has occurred or if a fast-start failover has been requested by the DBMS_DG.INITIATE_FS_FAILOVER function. The steps in this section describe the tasks involved to perform a manual failover. Oracle Data Guard helps you change the role of databases between primary and standby using either a switchover or failover operation. You must set both Initiate reinstatement by mounting the database. specified by the ObserverPingInterval property. For example: Using DGMGRL, you can do this by examining the output of the SHOW CONFIGURATION LAG. By default, the broker always determines whether bystander standby databases will be viable standby databases for the new primary when performing a complete failover. Make sure everything is working before moving on. The procedure for using RMAN to create a standby database is fully explained in Appendix F of Oracle Oracle Data Guard Concepts and Administration document (10g Rel 2 and 11g Rel 1). An observer is an OCI Restore - Flashback Database restores the datafiles to the closest snapshot prior to the specified SCN. Oracle Database PL/SQL Packages and Types Reference, Stop the observer from any computer system in the broker configuration, as described in, Start the observer on the new computer system, as described in Step 8 of, Enable fast-start failover using the DGMGRL, Shut down the primary database and the target standby database using either DGMGRL, Oracle Database Global Data Services Concepts and Administration Guide, Oracle Real Application Clusters Administration and Deployment Guide, Configure the connect descriptor for connect-time failover. When both databases have been restarted, you may restart the observer. on ob3-host and ob4-host will not fsfo_hostname.dat. In case of primary database failure, you will need to perform failover to transition the standby database to the primary role. You can also switch the master observer hosts for a group of configurations to one specific host. command START OBSERVER IN BACKGROUND. The other configurations that are not required but they might make your fast-start failover go smoothly. (This is useful because the name defined in the metadata may contain whitespace and international characters, which the observer configuration file does not allow.). On the Oracle Data Guard Overview page, click Database must be reinstated. created under this directory by DGMGRL will also have the same permissions. Use the FastStartFailoverTarget configuration property on the current primary database to specify one or more fast-start failover targets. Note that primary and standby databases must be licensed for Oracle RAC or Oracle Active Data Guard in order to use Application Continuity. Each observer has its own log file. Provides an automatic failover environment JAVA applications can use FAN programmatically by using the JDBC FAN application programming interface to subscribe to FAN events and to execute event handling actions upon the receipt of an event. If the protection mode was at maximum availability or maximum performance, it remains unchanged. In these sample commands, the ellipse () signifies any other add service options you wish to supply. fast-start failover succeeds, if a post-callout script is specified in the fast-start Use Cloud Control or DGMGRL to perform either a complete (recommended) or an immediate failover. If the specified log file is not accessible, or the LOGFILE IS option is not used, then the observer output is sent to standard output. An observer can be moved from one computer to another through a process of stopping it on one system and and re-starting it on another. Oracle Data Guard can switch a standby database to the primary role in case a production database becomes unavailable due to . If automatic reinstatement fails, the broker will log errors and the former primary database will remain in the mounted state. After the broker receives the STOP OBSERVER request, the request is passed to the observer the next time the observer contacts the broker, and the observer then stops itself. Verify there are no active users connected to the databases. To avoid problems due to timing variations, values less than 60 minutes are not recommended and values of 30 or less virtually guarantee Flashback Database failure. If you initiated a complete failover and it fails, you might need to use immediate failover. The default value is 30 seconds. Do this prior to every failover test. In a complete failover, it is also possible to failover to a standby database (terminal standby) that gets redo from another standby database (cascader). To verify the observer is started and the configuration is ready for The SRVCTL utility does not automatically take the database role into account, so any time you start a service manually, you must specify the name(s) of the service you want started. For example: The following example shows the fast-start failover information for the DRSolution configuration: The following SHOW OBSERVER command displays information about multiple observers in the DRSolution broker configuration. Make sure that xdpyinfo exist under PATH variable. 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. Oracle Data Guard configuration with DGMGRL. See Choosing a Target Standby Database for helpful advice. Reinstatement is supported only after failover in a broker configuration. variable must have read, write, and execute permissions for the directory owner It will also alert you to databases that have had Flashback Database disabled at some point after FSFO was enabled. Note: this state also occurs on the primary during startup when fast-start failover is possible and neither the target standby database nor the observer are present to confirm it is okay to continue opening the database. The master observer cannot connect to the target standby database, What Happens if the Observer Fails? Read-Only Standby and Active Data Guard observer_hostname.log. (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.). the primary database and the target standby database do not have a network The terminal session will appear to hang at this point. Data Guard Switchover/failover to standby The standby database will be activated to serve as the primary database at some point in its life cycle. This is typically done for planned maintenance of the primary system. The remaining Data Guard-related parameters will be set by Broker later in the walkthrough. 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 broker log files. See Sources of Diagnostic Information for details about the broker's drc* log files. Make sure the last redo data transmitted from the Primary database was applied on the standby database. After the database has been re-created, enable broker management of the re-created standby database by using the DGMGRL ENABLE DATABASE command. 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. It provides a way to quickly restore a database to a previous point in time or SCN using on-disk data structures called flashback logs. At a minimum, you must set db_unique_name. Fast-start failover will not be attempted for the other types of database shutdown (NORMAL, IMMEDIATE, TRANSACTIONAL). the ObserverPingRetry and ObserverPingInterval properties to achieve The subdirectories that DGMGRL creates under this directory will also have the configuration file OBSERVER command, if this directory does not have the For information about event notification and database connection failover support for global services, see the Oracle Database Global Data Services Concepts and Administration Guide. You must determine which available standby databases should be targets for failover. Improper Oracle Net configuration is a leading cause of reported FSFO issues. To start an observer as a background process, use the DGMGRL disable fast-start failover with the FORCE option on the Step-B: Copy control file to temporary location on primary database. The target standby database is enabled and is in the APPLY-ON state. from another DGMGRL session. See FastStartFailoverTarget for more information about this property. Examples of starting observers using DGMGRL are included in Scenario 6: Enabling Fast-Start Failover and Starting the Observer. Default value is 10 miliseconds. You Failover automation ensures a seamless transition from the primary database to a synchronized standby database in cases of failure, while ensuring database availability by replaying uncommitted in-flight transactions. The following steps all require the database to be in a mounted (not open) state. But it will also continue trying to reconnect to the primary database indefinitely. 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. Do not use Shared Server (formerly MTS) for Data Guard. . By default the file is named fsfo.dat and is created in the working directory where the observer is started. An application should use caution when calling the DBMS_DG.INITIATE_FS_FAILOVER function because the observer will initiate failover, if at all possible. Then, on the Fast-Start Failover Change Mode page, click Enabled. After step 3 completes, you can open the new Primary database STAN: There may or may not be data loss depending upon whether your primary and target standby databases were synchronized at the time of the primary database failure. This walkthrough assumes that all ORLs and SRLs on the primary and standby databases are the same size. The observe-only mode for fast-start failover enables you to test how fast-start failover will work in your environment. The primary database can be reinstated if it had flashback database enabled. Any standby database that was disabled by the broker must be reinstated or re-created, as described in Reenabling Disabled Databases After a Role Change, before it can be a standby database for the new primary database. Once the observer has initiated a fast-start failover, the primary database shuts down automatically. The services include switchover, switchback and failover. 2. To disable fast-start failover, use the Fast-Start Failover wizard in Cloud Control or the DGMGRL DISABLE FAST_START FAILOVER [FORCE] command. 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) after the switchover is completed. You can switch back to the original primary and then either retry the switchover to the original target standby, or choose another standby in the configuration to switch over to. To get started, all you'll need is Oracle Database Enterprise Edition Release 10.2 or later, a database, and three hosts: two for the databases and a small host for the FSFO observer. Fast-Start Failover in Oracle 11g Data Guard. Prepare the primary database in advance for its possible future role as a standby database in the context of the overall protection mode (see Managing Data Protection Modes). The values that indicate FSFO is ready for failover are listed below. If these parameters are modified outside of Broker, it raises a warning. 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. Starts redo transport services to begin transmitting redo data to all bystander standby databases that were not disabled. Initiate the failover on the standby database STAN: Note: Data Guard requires dedicated server connections for proper operation. Use Broker's "show configuration" command to determine FSFO status and the "show database