To disable fast-start failover, use the Fast-Start Failover wizard in Cloud Control or the DGMGRL DISABLE FAST_START FAILOVER [FORCE] command. Note that enabling FSFO does not make the configuration ready for automatic failover - that requires an observer, which we'll get to next. prolonged stall, either the observer or target standby database Make sure the last redo data transmitted from the Primary database was applied on the standby database. In 10g, a single wallet can be used for multiple observers, but they must all use the same SYS password. In an immediate failover, it is also possible to failover to a standby database (terminal standby) that gets redo from another standby database (cascader). Regards, Narottam Tagged: dataguard dba rac Welcome! This results in the observer establishing a new connection to the primary database every 30 seconds. Flashing back a database occurs in two stages: For FSFO environments, set db_flashback_retention_target = 60 or higher to provide sufficient Flashback Database history for automatic standby reinstatement. In the restore stage, Flashback Database restores the database to a point prior to the standby_became_primary_scn using the before-image blocks in the Flashback Database logs. The act of switching roles should be a well-planned activity. A switch-over allows the primary database to switch roles with its standby database. FastStart Failover Ensues: Disaster strikes the primary database and its network connections to both the observer and the target standby database are lost. You must ensure that the primary database is shut down prior to performing a manual failover. This directory is created when you run the If this operation is successful, a zero data loss failover may be possible even if the primary database is not in a zero data loss protection mode. The ObserverPingInterval Fast-start failover allows the broker to automatically fail over to a previously chosen standby database in the event of loss of the primary database. The database on which the procedure is called notifies the observer. ORACLE instance shut down. There is no need to multiplex SRLs in order to protect redo as with ORLs (the redo is already protected in the ORLs of the primary). The broker allows an immediate failover to proceed even if there are errors present on the standby database that you selected to participate in the failover. If the broker performs a switchover or failover, then it starts the service SALESRW or SALESRO based on the current role of the database. For example: Scenario 6: Enabling Fast-Start Failover and Starting the Observer. fast-start failover to the target standby database if conditions warrant a failover. Failovers become routine. Data Guard Broker - Controls the creation and monitoring of Data Guard. set the ObserverPingInterval and Alternatively, if you intend to switch back to the original primary relatively soon, then you may re-enable the disabled standby databases after the switch back. In the previous article, we have seen switching the role of Primary and standby database and failover Primary role to Standby database manually. See Manual Failover for complete information about manual failovers. For this reason, you should first issue this command on the target standby database. To start an observer, you must be able to log in to DGMGRL with an account that has More specifically, we can have an asynchronous second read-only Managed instance in the same or in a different region. Disabling fast-start failover with the FORCE option when connected to the target standby database guarantees that fast-start failover will not occur. Displays only on a logical standby database that has not yet completed loading a copy of the primary database's data dictionary. If you have not used the SET ObserverConfigFile command after starting the current DGMGRL client, then the result will always be: ObserverConfigFile=observer.ora. PeopleSoft can be configured for Active Data Guard. It has two parts in the following order: Configuration declaration this section is mandatory. To avoid the overhead of recording every change to every block, Flashback Database takes a "fuzzy" snapshot every 30 minutes and only records the before-image block upon its first change since the last snapshot. 1. If the target is a snapshot standby database, the broker first converts the database to a physical standby database. Note that the new primary database does not need to be restarted. Oracle Real Application Clusters Administration and Deployment Guide for information about Application Continuity, The broker simplifies switchovers and failovers by allowing you to invoke them using a single key click in Oracle Enterprise Manager Cloud Control (Cloud Control) or a single command in the DGMGRL command-line interface (referred to in this documentation as, Ensure that the standby database you choose to be the target of fast-start failover has its, Oracle Data Guard Concepts and Administration. In maximum availability mode, the behavior depends on the value of the This section will help you get started with creating a wrapper script to automatically start and restart the FSFO observer. You In the following example, ObserverReconnect is set to 30 seconds. A far sync instance or Zero Data Loss Recovery Appliance is not a database and therefore cannot be the target of a role transition. You need to consider all of the options at the time you are building your Oracle Data Guard configuration, including factors such as the characteristics of physical standbys versus logical standbys versus snapshot standbys, the network latency to your standby database sites, the computing capabilities at a future primary database site, and so on. databases (PDBs) on any of the instances. An observer process is integrated in the DGMGRL client-side component of the broker and typically runs on a different computer from the primary or standby databases and from the computer where you manage the broker configuration. Oracle Corporation recommends that you specify this type of failover. A single-instance database must be registered with Oracle Restart in order to publish FAN events via ONS. The targets are referred to as candidate targets. 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. See Enabling Fast-Start Failover for more information. Oracle Data Guard with Fast-Start Failover (FSFO) can provide additional resiliency by setting up the broker on a separate machine. Before a Overview of Switchover and Failover in a Broker Environment. Broker will verify that the configuration meets all prerequisites before enabling FSFO and will report any problems it finds. While not strictly required, creating a wallet provides a secure way to store the credentials needed to automatically connect to the primary when starting the observer. In a DataGuard environment when the Primary instance fails you need to go through the Failover and Reinstate processes in order to restore the database service, as described in the documentation: Changes a standby database to the primary role in response to a primary database failure. In a Managed Instance with multiple databases in Azure we can have high availability. Use synonyms for the keyword you typed, for example, try "application" instead of "software.". FastStartFailoverLagLimit property. FastStartFailoverThreshold for reference information about the FastStartFailoverThreshold property. You can issue a How to Re-create and Reenable a Disabled Database. If the switchover occurs to a physical standby database, and the former primary 3. SQL>SHUTDOWN IMMEDIATE; STOP OBSERVING [cfg_group_name] stops LOCAL observers running on this host (where this DGMGRL is running) for all broker configurations in a specified group. Displays if the standby database's redo applied point lags the primary database's redo generation point by more than the number of seconds specified by the FastStartFailoverLagLimit configuration property and the configuration is operating in maximum performance mode. The target standby database has contact with the primary database. Other members of the configuration will receive redo from the designated redo source based on the new primary. They rely on Oracle Data Guard for high availability databases, with a standby database running in a different availability zone. The following sections describe how to reinstate or reenable a database. Instead, the old primary database must be re-created as a standby from a backup of the new primary using the procedure described in How to Re-create and Reenable a Disabled Database. Oracle 12c-Step by Step Manual Data Guard Failover. Configure the protection mode. If automatic reinstatement fails, the broker will log errors and the former primary database will remain in the mounted state. FastStartFailoverLagLimit specified by the ObserverPingInterval property. change tracking enabled, broker enables block change tracking on the new Note: If you have just enabled archivelog mode, force an archive log creation ( alter system archive log current) to ensure that at least one archive log exists. It's generally a good idea to store the state file in a directory associated with the database to avoid locking issues when running multiple observers on the same host. computer, it automatically starts the observer when you enable Oracle Database 10g databases running versions prior to 10.2.0.4 will remain in a stalled state until aborted or signaled to remain the primary by the observer once connectivity has been restored. When the configuration has only one registered observer, 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. You can also specify a list of ORA- errors that will initiate FSFO failover. Initiate reinstatement by mounting the database. Learn how to use Oracle Data Guard broker to manage databases during switchover and failover. the primary database that failed or took longer than the time The group of broker configurations to be managed is declared in the observer configuration file. If the Cloud Control agent is installed on the observer An spfile is required to persist these changes. under the $DG_ADMIN directory. This is true regardless of the settings for the FastStartFailoverPmyShutdown and FastStartFailoverAutoReinstate configuration properties. 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). value of the FastStartFailoverThreshold property. Staff support, hardware and software, security (both software and site), network connections, and bandwidth should be equivalent at both sites. If you are more concerned about the performance of the primary database than a minimal loss of data, consider enabling fast-start failover when the configuration protection mode is set to maximum performance. Testing FSFO failover requires simulating loss of the primary. This table describes the optional database properties that you can set. If both HVR and Data Guard were running without latency or if no changes were made to the source database at the time of the failover, it can be assumed that all databases are synced and the no extra steps are necessary; the steps for Graceful Failover can be followed. Waits for the target standby database to finish applying any unapplied redo data before stopping Redo Apply (if the target is a physical standby database) or SQL Apply (if the target is a logical standby database). In an environment where there are multiple observers configured, stopping the master observer is not allowed unless it is the last running observer. 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. While this eliminates the processing overhead associated with periodically establishing a new observer connection to the primary database, it also prevents the observer from detecting that it is not possible to create new connections to the primary database. This will signal the observer to initiate failover after the FSFO threshold timeout has been reached (default is 30 seconds). environment that is guaranteed to either lose no data (when the It is not reversible. A switchover is a role reversal between the primary database and one of its standby databases. See the Cloud Control online help for more information. After the conversion, the broker will start Redo Apply to apply accumulated redo data, before failing the database over to the primary role. The example uses the FROM ACTIVE DATABASE clause introduced in 11g that allows RMAN to create a standby database by copying the primary across the network without the need to store the backup files on disk or tape. In this example, the original primary data is called PRIM and the original standby database is called STAN. OBSERVE-ONLY: Fast-start failover is enabled in observe-only mode. See Directing a Fast-Start Failover From an Application). Your email address will not be published. isolated. If you do not want to use the default, you can define a specific group. fast-start failover operation, the observer checks if a fast-start failover This is To optimize the log apply rate: Do not configure the DelayMins database property to delay applying archived redo log files to the standby database (see Managing Log Apply Services for more information). Fast-start failover is inhibited in this case. This exercises the configuration, but triggers failover differently than losing contact with the primary. If that metadata is pushed out, Oracle can no longer find a fuzzy snapshot so it will not be able to flash back. If the value is non-zero, failover is possible any time the standby database's apply This support note is available at http://support.oracle.com. Such preparation includes: Ensuring that standby redo log files are configured on the primary database. occur. START OBSERVING [cfg_group_name] starts a new observer for each broker configuration in the specified group. Oracle Database PL/SQL Packages and Types Reference for more information about the DBMS_DG package. alter database recover managed standby database finish; alter database activate standby database; Managed recovery process has been stopped between primary and standby database and standby becomes primary database. failure on the primary database. These tasks assume that you are connected as SYS or SYSDG and that a primary and standby database are already set up in a broker configuration. . 8.2 Private Cloud Appliance and . Depending on the failover and the types of standby databases involved, some of the databases may need to be reinstated or re-created. If the primary database can be mounted, it may be possible to flush any unsent redo data from the primary database to the target standby database using the ALTER SYSTEM FLUSH REDO SQL statement. the current working directory, Uses standard output for displaying the observer logs. Simply use DISABLE FAST_START FAILOVER. 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. Before stopping an observer, note the following: The observer does not stop immediately when you issue the STOP OBSERVER command. specified, the file is stored in an appropriate directory under the broker's The RedoRoutes property on the primary if the new value would result in the primary not being able to ship redo to the current fast-start failover target standby. The current primary database must have its LogXptMode property set accordingly and must have standby redo logs configured. At this point, you can either: Disable fast-start failover (described in Disabling Fast-Start Failover) and attempt to open the former primary database, Manually reinstate the former primary database, as described in Reenabling Disabled Databases After a Role Change. This prevents a "split brain" condition if a failover occurs since none of the changes made to the isolated primary can be made permanent. This file is stored in the To allow the database to register with the Data Guard listener, the listener endpoint must be added to the database's local_listener parameter. Create a script to automate FSFO failover initiation and use it as your standard method for standby flips. If a fast-start failover was initiated because the primary database had crashed or lost connectivity with the master observer and target standby database, then the master observer automatically attempts to reinstate the former primary database as a standby database, if the FastStartFailoverAutoReinstate configuration property is set to TRUE. Twitter:https://twitter.com/hariprasathdba, In The following steps all require the database to be in a mounted (not open) state. Starting the Observer as a Background Process Using You must re-create the database manually from a copy of the current primary database and then reenable the database in the broker configuration. SWITCHOVER command, and the databases are managed by Oracle Note: Data Guard requires dedicated server connections for proper operation. The observe-only mode for fast-start failover enables you to test how fast-start failover will work in your environment. Oracle Database 11g observers are incompatible with 10g databases and vice-versa. If the primary is unable to contact the standby after a user specified period of time (NET_TIMEOUT option of log_archive_dest_ n), it drops out of synchronous transfer mode and begins operating as though it were in Maximum Performance mode. Now it will return PRIMARY. The following is an example of querying the V$FS_FAILOVER_STATS view: Disabling fast-start failover prevents the observer from initiating a failover to the target standby database. Switch-over steps: Step-A: Shutdown primary database: SQL> shut immediate; Database closed. Displays when the primary and target standby databases are synchronized and the configuration is operating in maximum availability mode. It behaves similarly to START OBSERVING and STOP OBSERVING to operate on all the configurations defined in the observer configuration file. To prevent automatic reinstatement of the former primary database in these cases, set this configuration property to FALSE. Reinstatement will have to be accomplished by other means (manual or scripted Broker commands). Its primary job is to perform a failover when conditions permit it to do so without violating the data durability constraints set by the DBA. Data Guard uses Oracle Net (SQL*Net) for communication between the primary and standby databases and the FSFO observer. The lowest possible value is 5 seconds. failover configuration file, this script is run. ORACLE instance shut down. STANDBY> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; Fast-start failover will not occur unless all instances comprising the Oracle RAC primary database are perceived to have failed. created under this directory by DGMGRL will also have the same permissions. Oracle Database 11g FSFO adds support for Maximum Performance mode (async redo transfer), providing the flexibility to trade durability for performance. Displays the current fast-start failover mode. an alias of the broker configuration name. The primary and target standby must have connectivity for the STOP OBSERVER command to complete successfully. See the Cloud Control online help for more information. the names of the scripts created in the previous step. These are some points to consider before you begin a switchover. You can manage observers through either the Oracle Data Guard Overview pages in Cloud Control or using DGMGRL commands. Is possible if the target standby database displays SYNCHRONIZED and the FS_FAILOVER_OBSERVER_PRESENT column displays YES. An immediate failover is the fastest type of failover. SQL Apply on all other bystander standby databases automatically begin applying redo data received from the new primary database. the primary role, use the PreferredObserverHosts Managed recovery process has been stopped between primary and standby database and standby becomes primary database. If both of those observers are unavailable, the observers If clients are already configured to automatically time out and reconnect if they don't get a response from the database, a simple but effective approach is to use a network alias (e.g. Issue the following SRVCTL commands: Now the correct services are running on the correct databases. When this property is set to the default value of 0, it prevents the observer from periodically establishing a new connection with the primary database. Regardless of the method you choose, the broker coordinates the role transition on all databases in the configuration. Time for action - using interfaces to monitor Data Guard; Other replication solutions and Data Guard; It could optionally also be removed from the primary database if there is no intention to ever run this service on the current primary database. 2. In cases where These are the actions the broker performs after you start a switchover. ConfigurationSimpleName. The primary database can be opened even if there is no acknowledgement from the observer or target standby. If one of these errors has occurred, follow the guidelines in "Resolving ORA-752 or ORA-600 [3020] During Standby Recovery" in My Oracle Support Note 1265884.1 before proceeding. In Maximum Availability mode, FSFO guarantees that no transaction that has received a commit acknowledgment will be lost during a failover. The former primary database is disabled. Databases that can be reinstated will have the following status value: For the REINSTATE command to succeed, Flashback Database must have SHOW OBSERVER command to confirm that the switch took place. We'll start with switchovers. It is actually a low-footprint OCI client built into the DGMGRL CLI (Data Guard Broker Command Line Interface) and, like any other client, may be run on a different hardware platform than the database servers. https://www.facebook.com/dbahariprasath/? The standby can be physical or logical and there can be multiple standbys, but only one of the standbys can be the failover target at any given time. To protect the files, it's good practice to store them in separate filesystems. command START OBSERVER IN BACKGROUND. Any broker configuration name that is referred to must exist in the configuration declaration section. files are stored in subdirectories of the DG_ADMIN directory. If there are many actions that need to take place, put them in a separate script and use the trigger to run the script in an orphan process or thread independent of the database. To achieve It doesn't consider how much of that redo has been applied. Many customers use Oracle Database deployed on Amazon Elastic Compute Cloud (Amazon EC2) to run their Oracle E-Business Suite applications. It is very much useful, when the organization has multiple standby sites. The service is then configured to be active in the PRIMARY role on the standby database SOUTH, so that it will be active on that database after a role transition. Read-Only Standby and Active Data Guard A simple example for *nix is provided below that will work with both releases. commands. Fast-start failover is enabled, but this standby database is not the target of the fast-start failover. Now it will return PRIMARY. The My Oracle Support note 1625597.1 at http://support.oracle.com for information about compatibility requirements between the observer and DGMGRL, Starting Multiple Observers on a Data Guard Broker Configuration. Steps for FAILOVER the Dataguard environment 1. Once an immediate failover is started, the broker: Verifies that the target standby database is enabled. Install the DGMGRL command-line interface on the observer computer as described in Oracle Data Guard Installation. You can use this information to identify ahead of time any redo transport configurations that would be incorrect after a role change, including any standbys that will not receive redo because the RedoRoutes property was not configured correctly. Note the primary and target standby must have connectivity for this command to complete successfully. Sets up redo transport from the new primary to the other members of the configuration, Starts Redo Apply services on the new standby, Ensures the other standbys in the broker configuration are viable to the new primary, Integrates with Oracle Clusterware and Oracle Global Data Services (GDS) to ensure that the proper services are started after a role change. database's redo generation point by more than the value specified by the See START OBSERVER IN BACKGROUND for more information Since a fast-start failover (automatic failover) could become a false failover when the observer or the standby database cannot connect to the primary database within a specific time, which may cost the database to lose some transactions followed by reinstating or recreating the standby database (the former primary database). physical standby database. configuration named ConfigurationSimpleName. If fast-start failover is enabled, then 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 or is within the configured lag limit, for the max availability and max performance modes respectively. Note that the broker does not use the properties to set up redo transport services and Redo Apply services until you actually switch over the primary database to the standby role. Most in-progress failures cannot be restarted (for example, archived redo log file corruption on the primary database). In order to maintain separation of Broker and non-Broker activity, a second static service is recommended. If you are performing a complete failover, then all accumulated redo data is applied before the database role is changed to primary.