if the observer is not running, The master observer and the target standby database are inconsistent with regard to the current state of the broker configuration, If the protection mode is maximum availability or maximum protection and the target standby database was not synchronized with the primary database at the time the primary database failed, If the protection mode is maximum performance and the apply point of the target standby database lags the redo generation point of the primary database by more than the amount specified by the FastStartFailoverLagLimit configuration property at the time the primary database failed. In order to fully automate switchover, Broker needs SYSDBA credentials in order to restart one or both databases. Issue the following command while connected to any database in the broker configuration, except the database that is to be reinstated: The newly reinstated standby database will begin serving as a standby database to the new primary database. An spfile is required to persist these changes. Starting the Observer as a Background Process Using The configuration must be operating in either maximum availability mode or maximum performance mode in order to be able to switch over to a logical standby database. command for more information about starting the This may take a few minutes. Set both these properties to achieve a primary failure detection time of 1 STAN is now transitioned to the primary database role.Now your PHYSICAL STANDBY Database has become PRIMARY. We could not find a match for your search. If this is an Oracle RAC physical standby database managed by Oracle Clusterware, then the broker directs Oracle Clusterware to restart the new standby database. If the observer finds that the database is no longer the primary, it will attempt to reinstate it as the failover target standby. But it will also continue trying to reconnect to the primary database indefinitely. 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 primary database must be running in order to start the observer. maximum availability and maximum performance modes, to avoid a To run an observer as a background process, use the DGMGRL command START OBSERVER IN BACKGROUND. the primary role, use the PreferredObserverHosts You must ensure that the primary database is shut down prior to performing a manual failover. 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. Reenabling Disabled Databases After a Role Change describes how to restore their viability as standby databases. You cannot create the standby DB system in a different AD from the primary DB system. Currently, this state can be detected only when the database is open. Configure the protection mode. A far-sync instance cannot be used in maximum protection mode. Open another prompt and connect to SQLPLUS: LGWR is unable to write to any member of the log group because on an I/O error. Remote login is required, along with a password file, to allow the databases in a Data Guard configuration to connect to each other. If you have an Oracle RAC primary database, consider specifying a higher value to minimize the possibility of a false failover in the event of an instance failure. To install Oracle Data Guard, you need to create two Azure VMs on the same availability set: The primary VM (myVM1) has a running Oracle instance. You can manually stop a specific observer or all observers. If the former physical standby database was running with real-time query enabled, the new physical standby database will run with real-time query enabled. November 20, 2009. prolonged stall, either the observer or target standby database If the WAIT option is included in the Table 6-2 FS_FAILOVER_STATUS Column of the V$DATABASE View. 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. While Oracle 11g's Data Guard definitely protects a database when the entire production site is lost via its failover capabilities, it's still necessary for an Oracle DBA to intervene to complete the failover process. stored in the specified path using the default file names. In fact, failovers are so reliable, fast, and simple that switchovers become the exception rather than the rule. After setting local_listener, register the database with the listener and verify the services have been registered. The values that indicate FSFO is ready for failover are listed below. To start the observer with DGMGRL, issue the following Performing failover : Step 1: Check Standby Database role. There are normally two situations when this operation will be performed: a planned outage for maintenance of the primary database or disaster recovery. The database on which the procedure is called notifies the observer. 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. To stop the observer when fast-start failover is disabled, the primary database must be running. RAM). alter system set standby_file_management=auto; This parameter must be set before the primary can be opened in Maximum Availability mode. Choosing the standby database with the smallest transport lag can minimize the amount of data loss and in some cases, incur no data loss at all. North_Sales is in the primary role. For zero data loss in maximum availability mode, the FastStartFailoverLagLimit property must be set to zero. This section describes how to stay on top of your FSFO environments. See Manual Failover for complete information about manual failovers. In an Oracle Data Guard configuration, the SRVCTL -startoption for a standby database is always set to OPEN after a switchover. Broker will set the primary to use asynchronous log transport by default. Subsequent changes to the same block during the same snapshot are not recorded. Any broker configuration name that is referred to must exist in the configuration declaration section. Observer uses the value of the DGConnectIdentifier property to connect to and monitor the primary and target standby databases. not already enabled, the observer waits until fast-start failover If fast-start failover is enabled you can still perform a switchover or a manual failover as long as certain conditions are met. ensure that it has the required permissions. A snapshot standby cannot be the target of a switchover or fast-start failover operation. See Performing Manual Role Changes When Fast-Start Failover Is Enabled for more information. If you are performing a complete failover, then all accumulated redo data is applied before the database role is changed to primary. If the broker performs a switchover or failover, then it starts the service SALESRW or SALESRO based on the current role of the database. The observer is the third party in an otherwise typical primary/standby Data Guard configuration. In a separate terminal session, verify the configuration. Your email address will not be published. In such a case, no attempt is made to transmit any unsent redo from the cascader to the terminal standby. Fast-start failover is inhibited in this case. The target standby database has contact with the primary database. There are many examples, and Ritesh Chhajer offers this example of doing a Data Guard switchover using dgmgrl: 1. Valid values are >= 10. 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. In maximum protection mode, an automatic failover is always possible because the The price for this guarantee is increased commit latency ( log file sync waits). SQL>ALTER SYSTEM SWITCH LOGFILE; SHOW CONFIGURATION VERBOSE, or SHOW OBSERVER Examine the Broker configuration by logging into dgmgrl on the new primary. The minimum value is 100 milliseconds. Note: the FSFO observer version must match the database version. Add the SRLs. Displays if the standby database's redo applied point does not lag 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. operation: Example 6-1 Fast-start Failover Configuration Stop the observer using the DGMGRL STOP OBSERVER command. When enabled, re-create the standby database. In short, the failover is the deformation of the production (primary) database and activating standby database as the primary. Standby databases not involved in the switchover (known as bystander standby databases) continue operating in the state they were in before the switchover occurred and will automatically begin applying redo data received from the new primary database. 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. PDBs. failover with the FORCE option on the primary database. See Enabling Fast-Start Failover for more information. You can also switch the master observer hosts for a group of configurations to one specific host. Reenabling Disabled Databases After a Role Change describes how to do this. In this mode, the FastStartFailoverLagLimit configuration property is set to zero. Errors occurring for any other configuration members will not impede the switchover. Conditions shown in blue are enabled by default. ObserverConfigFile is a DGMGRL session runtime property. 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. MASTEROBSERHOST TO command. Flashing back a database is much faster and more seamless (one simple DDL statement) than traditional point-in-time or SCN-based recovery. If that metadata is pushed out, Oracle can no longer find a fuzzy snapshot so it will not be able to flash back. It is then configured to be active in the PHYSICAL_STANDBY role on the physical standby database SOUTH. Once fast-start failover is enabled, the broker will ensure that fast-start failover Regards, Narottam Tagged: dataguard dba rac Welcome! A complete failover also attempts to avoid disabling any standby databases that were not the target of the failover, so that they may continue serving as standby databases to the new primary database. The broker first converts the original primary database to run in the standby role. After step 1 finishes, Switch the original physical standby db STAN to primary role; OBSERVE-ONLY: Fast-start failover is enabled in observe-only mode. Nothing will ruin your day faster than finding out that the standby the observer just failed over to is 12 hours behind in applying redo. In addition, a logical standby database may contain only a subset of the data present in the primary database. That process is shown here. flashback logs on that database. Permissions Required by the DG_ADMIN Directory. If the PreferredObserverHosts property is set for the current The configuration and database status report that the observer is not running and return one of the following status messages: While the configuration is in the unobserved state, fast-start failover cannot happen. The environment is a single instance database without any grid Infrastructure components. Issue the DISABLE FAST_START FAILOVER command or the DISABLE FAST_START FAILOVER FORCE command. property. FSFO builds upon a number of other Oracle technologies and features such as Data Guard, Flashback Database, and Data Guard Broker. Cloud Control will start the observer. To start an observer as a background process, use the DGMGRL If any errors occur during either conversion, the broker stops the switchover. Before beginning a failover, first determine that there is no possibility of recovering the primary database in a timely manner, and ensure that the primary database is shut down. 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. add service command. After FSFO is enabled, Broker will continue to check that Flashback Database is enabled during health checks. Flashback Database records the before-image of changed blocks. Whether or not you need the FORCE option depends mostly on if the primary and target standby database have network connectivity: If the primary and target standby database have network connectivity, and the database to which you are connected has network connectivity with the primary database, the FORCE option has no effect. It will return PHYSICAL STANDBY, 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. SQL>select sequence#, applied from v$archived_log; For example: Fast-start failover occurs if both the observer and the target standby database lose connection to the primary database for the period of time specified by the FastStartFailoverThreshold configuration property. Broker keeps its configuration details in flat file. same permissions. There can be up to four The same thing happens if a shutdown and startup of either database occurs - the service that is started is the one that matches the role of the database being started. Among many benefits of using this utility, I highlight that while using it, it will not need manual intervention to recover the databases or eventually a switchover in case the primary database becomes unavailable. The Marketplace image that you use to create the VMs is Oracle:Oracle-Database-Ee:12.1..2:latest. orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID. Depending on the failover and the types of standby databases involved, some of the databases may need to be reinstated or re-created. Execute the following on primary database NORTH: Execute the following on the physical standby database SOUTH: If the broker now performs a switchover or failover, it automatically starts the SALES service on the correct database, based on the database's role. If fast-start failover is initiated, the master observer verifies the target standby database is ready to fail over to the primary database role. Enabling fast-start failover does not trigger a failover. You can disable fast-start failover if necessary, by using the FORCE option. configuration file (If there are other conditions, unique to an application, that would warrant a fast-start failover then the application can be set up to call the DBMS_DG.INITIATE_FS_FAILOVER function and start a fast-start failover immediately should any of those conditions occur. The broker controls the rest of the switchover. Switchover to a logical standby database is disallowed when the configuration is operating in maximum protection mode. operation can be automated using callout scripts. You can manage observers through either the Oracle Data Guard Overview pages in Cloud Control or using DGMGRL commands. SWITCHOVER command, and the databases are managed by Oracle Staff support, hardware and software, security (both software and site), network connections, and bandwidth should be equivalent at both sites. The selected standby database that will be the fast-start failover target must receive redo directly from the primary database. This page will not allow you to alter the protection mode. 4. See Manual Failover for information about manual failover. For Oracle Database Release 12.2 and higher, Oracle Enterprise Manager Cloud Control (Cloud Control) supports configuring multiple observers using the Enterprise Manager Command Line Interface (EM CLI). On the Oracle Data Guard Overview page in Cloud Control, select the standby database that you want to change to the primary role and click Failover. The walkthrough begins with a single database that will become the primary of a Data Guard configuration. On primary database NORTH, execute the following: On standby database SOUTH, execute the following: Services that are to be active while the database is in the physical standby role must also be created and started on the current primary database regardless of whether the service will be started on that database or not. If the value is non-zero, failover is possible any time the standby database's apply Before stopping an observer, note the following: The observer does not stop immediately when you issue the STOP OBSERVER command. this script is run before the fast-start failover is initiated. The syntax for the optional definition of a broker configuration group is: The group definition section is optional. If you performed a failover or switchover that requires you to re-create the failed primary database or standby databases that were disabled during the role transition, then follow the procedures in the Oracle Data Guard Concepts and Administration chapter, "Creating a Physical Standby Database" and also the Oracle Data Guard Concepts and Administration chapter, "Creating a Logical Standby Database.". Manual failover gives you control over exactly when a failover occurs and to which target standby database. It is possible to manually perform an immediate failover to a standby database that receives redo data from a far sync instance. Examples of starting observers using DGMGRL are included in Scenario 6: Enabling Fast-Start Failover and Starting the Observer. For information about event notification and database connection failover support for global services, see the Oracle Database Global Data Services Concepts and Administration Guide. If the group name is not provided, then a new observer is started for each broker configuration defined in observer.ora. Contains the observer runtime data file for the broker Starting with Oracle Database Release 21c, use the DG_ADMIN The failed primary database requires reinstatement as a new standby database to the new primary. The state file is locked when the observer is running to prevent multiple observers from using the same file. 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. Therefore, the primary database can continue processing transactions, even if the target standby database fails. A broker configuration can belong to multiple groups. The following example shows you how to set up more than one service on a database and how using the broker ensures that the correct service starts on the correct database. created under this directory by DGMGRL will also have the same permissions. Restart the database to the mounted state, Use Cloud Control or DGMGRL to reinstate the database. observers are registered, a directory named Time for action - using interfaces to monitor Data Guard; Other replication solutions and Data Guard; When the configuration has more than one registered observer, if the primary and target standby databases stay connected but the connection to the master observer is lost, then the broker tries to nominate a backup observer as the new master observer. If they are isolated from each other, then you must first disable fast-start failover by using the FORCE option, and then stop the observer. WAIT option, broker waits for the amount of Notice that the terminal session appears to hang after starting the observer. 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. As shown in the table, fast-start failover can be enabled in maximum availability This may result in two databases in the configuration simultaneously assuming the primary database role. the observer was killed after the stall began, but before the failover timeout had elapsed). The role change is directed to the same standby database that was specified for the FastStartFailoverTarget database property on the primary database. $DG_ADMIN/config_ConfigurationSimpleName/callout FastStart Failover Ensues: Disaster strikes the primary database and its network connections to both the observer and the target standby database are lost. If fast-start failover is enabled and the Datafile Write Errors condition is specified, then a fast-start failover is initiated if write errors are encountered in any data files, including temp files, system data files, and undo files. See Installing and Starting the Observer. With FSFO enabled, Broker expects to find an observer, which we haven't started yet, so if you verify the at this point with 'show configuration', Broker will report a warning (if it doesn't, give it a minute to discover that the observer isn't there). You can use the broker's reinstate capability to make a failed primary database a viable standby database for the new primary. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role. Application Continuity is an Oracle Database feature that enables rapid and nondisruptive replays of requests against the database after a recoverable error that made the database session unavailable. Managed recovery process has been stopped between primary and standby database and standby becomes primary database. You must 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. Each observer has its own log file. Please contact us at email@example.com. 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. If you re-create the old primary database, it must be created as the standby type of the old standby database. These are the actions the broker performs after you start a switchover. This action may result in two databases in the configuration simultaneously assuming the primary database role. Fast-Start Failover in Oracle 11g Data Guard. FastStartFailoverThreshold for reference information about the FastStartFailoverThreshold property. 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. 1. Learn how to use Oracle Data Guard broker to manage databases during switchover and failover. 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. environment variable is set and the specified directory has the The new primary database starts transmitting redo data to the new standby database. 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. After Fast-Start Failover: The fast-start failover has completed and the target standby database is running in the primary database role. We'll start with switchovers. When you configure data guard using OCI console, the default mode is set to maxprotection. 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. This walkthrough uses Maximum Availability mode to achieve "zero data loss". In the event of a 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. must ping the primary database. observers for a single Data Guard configuration. Flashback Database stores its logs in the Flash Recovery Area (FRA), so the FRA must be large enough to store at least 60 minutes of Flashback Database history. Some of the statistics that can be monitored are as follows: LAST_FAILOVER_TIME that shows the timestamp of last fast-start failover, LAST_FAILOVER_REASON that shows the reason for the last fast-start failover. It is important that all SRVCTL add service options be identical on all the databases so that the services behave the same way before and after a role change. 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). Use the wrapper script to start the observer process when the observer host boots or to restart it if it dies. This post will demonstrate the procedure to test Oracle Data Guard Fast-Start Failover by shutting down the server where the primary database is running from. With a value of TRUE for this property, the primary will shut down after being stalled for the number of seconds specified by the FastStartFailoverThreshold property. This database property is used to specify how the observer should connect to and monitor the primary and standby database.