been enabled on the database prior to the failover and there must be sufficient 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. The walkthrough begins with a single database that will become the primary of a Data Guard configuration. Other logical standby bystander databases in the broker configuration will remain viable after the switchover. 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. All other registered observers are considered to be backup observers. For information about enabling fast-start failover, see Enabling Fast-Start Failover. If failover is not possible for some reason, then the master observer will continue checking whether the standby database is ready to fail over. However, there may be exceptions to the recommendation to choose a physical standby database as the target standby database. VALIDATE 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. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role. observers are registered, a directory named However, no additional data is applied on the standby database once you invoke the failover. It automatically sets Data Guard related database initialization parameters on instance start and role transitions, starts apply services for standbys, and automates many of the administrative tasks associated with maintaining a Data Guard configuration. FSFO configurations in Maximum Performance mode may limit potential data loss by specifying the maximum allowable age of transactions that are lost during a failover. fast-start failover has not occurred to the target standby database. After a switchover completes, the broker preserves the overall Oracle 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. SUSPENDED is cleared when connectivity with the primary database is restored. It is then configured to be active in the PHYSICAL_STANDBY role on the physical standby database SOUTH. select name,open_mode,database_role from v$database; Note: Note that if failover was performed on a snapshot standby database, the old primary must be either reinstated or re-created as a physical standby database. Before enabling fast-start failover, use one of the following techniques There can be up to four The original primary database will be restarted as a part of the switchover operation. You can specify STOP OBSERVER ALL to stop all observers registered in a broker configuration. The observer immediately initiates a fast-start failover, as long as the failover target database is in a valid fast-start failover state ("observed" and either "synchronized" or "within lag") to accept a failover. On Linux/Unix, the directory specified by the DG_ADMIN environment Starting Multiple Observers On a Single Host. Post failover, there are two methods of rebuilding your failed primary Method 1: Rebuild from scratch -> RMAN duplicate Method 2: Flashback database -> only if Flashback was enabled Reinstate failed primary: When you use data guard broker, with just one command, the primary can be rebuilt. 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. The broker will not allow a switchover to a standby that has an apply delay configured (DelayMins property is set to a non-zero value). return until you issue the STOP OBSERVER command To see if your primary has already met a prerequisite, follow the instructions in the Verify section. The following example displays the contents of the fast-start failover SQL> Select Database_role from v$Database; In this case, the primary database stalls and prevents any further transactions from To run an observer as a background process, use the DGMGRL command START OBSERVER IN BACKGROUND. The following sections describe these topics: Prerequisites for Enabling Fast-Start Failover, Viewing Fast-Start Failover Configuration Statistics and Status, Performance Considerations for Fast-Start Failover, Reinstating the Former Primary Database in the Broker Configuration, Shutting Down Databases In a Fast-Start Failover Environment. These requirements are supplemental to those described in the documents previously referenced and in the following client-specific guides: Oracle Data Provider for .NET Developer's Guide for Microsoft Windows. Just be sure to include a Flashback Database history check in the script to provide an option to abort if a failover would require a manual reinstate. To start the observer with DGMGRL, issue the following 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. 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 ready to failover). are configured correctly. the service configuration. 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. It behaves similarly to START OBSERVING and STOP OBSERVING to operate on all the configurations defined in the observer configuration file. Bounce your database and verify database name its open mode and its role: SQL> shutdown immediate; ORA-01109: database not open Database dismounted. To change the FastStartFailoverTarget property to point to a different standby database, disable fast-start failover, set the FastStartFailoverTarget property, and reenable fast-start failover. miliseconds. The environment is a single instance database without any grid Infrastructure components. In maximum protection mode, an automatic failover is always possible because the Synopsis. add service command. Use broker configuration properties to set the time taken to detect a ObserverConfigFile is a DGMGRL session runtime property. The observer does not attempt to reinstate the former primary database. second. 1,000,000 block changes on a small set of blocks generates less Flashback Database history than 1,000,000 changes on a larger set of blocks. there is a lost network connection, be aware that the observer may attempt a 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). This method will disable fast-start failover on all databases in the broker configuration. Create a wallet and set the default username and password to the database's SYSDBA credentials (usually SYS). See the START OBSERVER command for more information. Oracle Data Guard Command-Line Interface Reference for more information about these broker commands. Permissions Required by the DG_ADMIN Directory. See Installing and Starting the Observer. Default value is 10 miliseconds. . Instead, Oracle Clusterware opens PDBs on particular instances based on 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. maximum availability and maximum performance modes, to avoid a The target standby database is synchronized with the primary database if it is a configuration operating in maximum availability or maximum protection mode, or the target standby database is within the lag limit if it is a configuration operating in maximum performance mode. 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. These are the actions the broker performs after you start a switchover. 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. When a primary loses contact with both the failover target and the observer simultaneously, it enters a "stalled" state (v$database.fs_failover_status = 'STALLED') and any sessions still connected to the primary will block on commit. Some properties have changed between those releases. ORACLE instance shut down. The old Primary must have been running in flashback mode before the failover. To protect the files, it's good practice to store them in separate filesystems. status before the crash. Data Guard Broker - Controls the creation and monitoring of Data Guard. Oracle Database 11g adds the ObserverConnectIdentifier database property to the Broker configuration, allowing you to specify a connect identifier for the observer to use for monitoring the primary and failover target. A switchover guarantees no data loss and is typically done for planned maintenance of the primary system. If the client uses remote ONS subscription, the client must specify the hostname and port of the ONS daemon(s) of the primary database and each standby database. receives redo data from a far sync instance. In the media recovery phase, Flashback Database applies redo to bring the database up to the standby_became_primary_scn. The observer is perfectly satisfied if all of the redo it needs to meet your durability requirements has been received by the failover target. This results in the observer establishing a new connection to the primary database every 30 seconds. Start the Data Guard listener on both "a" and "b" hosts. That process is shown here. 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. A broker configuration can belong to multiple groups. Input commands are shown in shaded boxes in normal text. through these services to exit or for the specified wait time Prerequisites for Enabling Fast-Start Failover provides complete information about all of the fast-start failover and reinstatement requirements. The remaining observers are called backup observers. If you want to capture any logging generated by the observer, use the LOGFILE IS option on the START OBSERVER command, and ensure that the file name is unique. The name of the callout configuration scripts is specified in POTENTIAL DATA LOSS: Fast-start failover is enabled with some data loss. If you cannot tolerate any loss of data, then ensure that the configuration protection mode is set to maximum availability or maximum protection. To issue commands and interact with the If the observer finds that the database is no longer the primary, it will attempt to reinstate it as the failover target standby. Facebook:https://www.facebook.com/HariPrasathdba Opens the new primary database in read/write mode. Broker maintains these parameters by issuing ALTER SYSTEM commands as appropriate during role transitions, database startup/shutdown, and other events. 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. If the target is a snapshot standby database, the broker first converts the database back to a physical standby and then starts Redo Apply to apply all the accumulated redo before completing the failover and opening the database as a primary database. Alternatively, use the RedoRoutes property to configure the redo transport mode for the target standby and the database currently in the primary role. 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. If the DG_ADMIN environment variable is not set, or the distance. The log file name is specified with the LOGFILE IS option of the START OBSERVER command. Once the primary database regains connectivity with the target standby database, fast-start failover will be disabled for all the databases in the configuration. Unless action is taken to change the failover target to one of the bystanders, the new primary will be without a failover target until the former primary is reinstated as a standby. If the new primary database was a primary database in the past, and had block In this case, disable fast-start failover using the FORCE option on the target standby database. Use Broker's "show configuration" command to determine FSFO status and the "show database statusreport" command to drill down for details if Broker reports a problem. This is typically done for planned maintenance of the primary system. Database hosts are referred to as "a" and "b" hosts and the databases themselves are referred to as the "a" and "b" databases. The observer is very lightweight, requiring few system resources. 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. If there is only one registered observer, then it works in the same manner that a single observer worked prior to the advent of multiple observers in Oracle Database 12c Release 2 (12.2.0.1). In order to apply redo data to the standby database as soon as it is received, use Real-time apply. When DGMGRL starts, if the DG_ADMIN See Prerequisites for more information. This exercises the configuration, but triggers failover differently than losing contact with the primary. this script is run before the fast-start failover is initiated. groups used by multiple configuration commands. A switch-over allows the primary database to switch roles with its standby database. 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. The reinstated database acts as the fast-start failover target for the new primary database, making a subsequent fast-start failover possible. If there is only one observer, then it is considered to be the master observer. One is the master Bystander standby databases that are not disabled by the broker after the switchover will continue operating in the state they were in before the switchover. See Reenabling Disabled Databases After a Role Change for more information. North_Sales is in the primary role. The foundation of FSFO is Data Guard - a primary and at least one standby. RMAN will copy the spfile from the primary, so this init.ora file is only needed during the first phase of the duplication. may allow the primary database to continue redo generation after DGMGRL to manage multiple observers on multiple configurations. For more details about managing redo transport services using database properties, see Managing Redo Transport Services. Were sorry. In cases where If the primary or target standby databases lose connections to all backup observers, then the broker does not try to nominate a backup observer as the new master observer, and the broker reports that the configuration is not observed. Commit latency is not affected by redo transfer, but committed transactions whose redo has not been received by the standby will be lost during failover. The default value is ALL. Click Disable in the Fast-Start Failover wizard. ObserverPingRetry configuration properties. The group of broker configurations to be managed is declared in the observer configuration file. 2) Switchover/Failover option is disabled on Enterprise Manager.What are the steps to enable it so that I can do Switchover/Failover operation using OEM. under the $DG_ADMIN directory. Once the observer has initiated a fast-start failover, the primary database shuts down automatically. See Enabling Fast-Start Failover for more information. You want to prevent fast-start failover from occurring because the primary database will resume service soon. If the configured data loss guarantee cannot be upheld, That is, if the observer is connected to any instance in the Oracle RAC, all instances will show a value of YES. The target standby database has contact with the primary database. When a serious condition uniquely known to an application is detected, the application can call the DBMS_DG.INITIATE_FS_FAILOVER function to initiate an immediate fast-start failover. Application calls to DBMS_DG.INITIATE_FS_FAILOVER. Bystanders are part of the Data Guard configuration, but not part of the FSFO configuration. After setting local_listener, register the database with the listener and verify the services have been registered. Client-side broker Install the DGMGRL command-line interface on the observer computer as described in Oracle Data Guard Installation. ), The RedoRoutes property on a far sync instance if it is being used to receive redo from the primary database and ship redo to the target standby database, The standby database that is the target of fast-start failover, A far sync instance if it is being used to receive redo from the primary database and ship redo to the target standby database, Unless the conditions listed in Performing Manual Role Changes When Fast-Start Failover Is Enabled have been met, To a standby database that is not configured as the fast-start failover target. This list describes how the overall Oracle Data Guard protection mode is handled after a manual failover (complete or immediate). This document describes how to setup clients to connect to Data Guard databases (primary and standby) and configure automatic client failover such that in case there is role change due to switchover or . Set the, Configure the connect descriptor with a single network name that is registered with a global naming service such as DNS or LDAP. database that has the least amount of unapplied redo (smallest apply lag). For information about event notification and database connection failover support for global services, see the Oracle Database Global Data Services Concepts and Administration Guide. For example, to determine if fast-start failover can occur, the FS_FAILOVER_STATUS column displays either SYNCHRONIZED or TARGET UNDER LAG LIMIT and the FS_FAILOVER_OBSERVER_PRESENT column displays YES for the target standby database. Improper Oracle Net configuration is a leading cause of reported FSFO issues. physical standby database. 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. Displays the current fast-start failover mode. This feature enables RMAN to duplicate an existing database over the network without requiring a backup to disk or tape. For reliable startup, the initial connection should always be made to the primary. US Coast Guard Auxiliary. The ObserverPingInterval Setting it to 'FALSE' leaves the database open and stalled until it is terminated or signaled to proceed in the event a failover did not take place (e.g. An immediate failover should only be performed when a complete failover is unsuccessful or in the error cases just noted. instructions for the DGMGRL command-line interface. Issue the following commands on Primary database and Standby database to find out: ASYNC. The VALIDATE FAST_START FAILOVER command parses the callout It will return PRIMARY, Transitions the target standby database into the primary role, opens the new primary database in read/write mode, and starts redo transport services. 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. Now let's test switchover in the other direction. You must use the Oracle wallet to store the credentials for all broker configurations to be managed. 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. pre-callout configuration script and post-callout configuration script. Disabling fast-start failover does not stop the observer. Additionally, the new master observer is identified in the output shown for the SHOW FAST_START FAILOVER and SHOW OBSERVER commands. database (if real-time query is enabled). (Oracle Call Interface) client that connects to the primary and target standby databases 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). But before enabling Flashback Database, you must enable Flash Recovery Area (FRA). When you are experiencing network disconnections and you issue the DISABLE FAST_START FAILOVER FORCE command on the primary database or a standby database that does not have connectivity with the primary database, fast-start failover may not be disabled for all databases in the broker configuration. databases (PDBs) on any of the instances. This guide uses the naming convention of appending an underscore followed by a letter to the db_name to create the db_unique_name. must ping the primary database. Displays only on the target standby database when it is SYNCHRONIZED with or is TARGET UNDER LAG LIMIT of the primary database, has connectivity to the observer, but the primary database does not have a connection to the observer. fsfocallout.ora. A far sync instance or Zero Data Loss Recovery Appliance is not a database and therefore cannot be the target of a role transition. Immediate Failovers in Configurations Using Cascaded Standbys. (Note that the target standby cannot be a far-sync instance. the SYSDG or SYSDBA privilege. Bystander standby databases may be disabled by the broker during the failover, and they must be reinstated or re-created before they can serve as standby databases to the new primary database. directory. Figure 6-1 Relationship of Primary and Standby Databases and the Observer. It is not reversible. A high lag limit may lead to more data loss but may lessen the performance impact of the primary database. Alternatively, you can query the V$DATABASE view on the target standby database. When the conditions for fast-start failover are met, the Broker adds messages to the observer log and broker log indicating that fast-start failover would have been initiated. The connect descriptor must contain the SERVICE_NAME parameter in either case. To achieve This property specifies the amount of data, in seconds, that the target standby database can lag behind the primary database in terms of redo applied. This nomination is noted in the observer log file and in the broker log file (drc*.log). required permissions, fast-start failover callouts will fail. The NetTimeout property specifies the number of seconds LGWR will block waiting for acknowledgment from the standby in synchronous mode before considering the connection lost (corresponds to the NET_TIMEOUT option of log_archive_dest_n). file, observer runtime data file (fsfo.dat), fast-start failover callout You can manually stop a specific observer or all observers. For more information, see SET MASTEROBSERVER TO. 1. The price for this guarantee is increased commit latency ( log file sync waits). In this example, the original primary data is called PRIM and the original standby database is called STAN. failure on the primary database. This specifies how often the observer establishes a new connection to the primary database. To start an observer, you must be able to log in to DGMGRL with an account that has Once the observer is started, you cannot change the file's name and location. Switchover and Manual Failover for more information about switchovers and manual failovers, respectively. Only the observer can initiate FSFO failover. 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. Use the SHOW CONFIGURATION BystandersFollowRoleChange command to see the value of this property. Credentials Required for Access to Broker Configurations. Step-by-step instructions for manual reinstatement are described in Reenabling Disabled Databases After a Role Change. You may failover to a snapshot standby database. If a non-zero value is specified for the A normal shutdown prevents a fast-start failover until the primary database and standby database are connected and communicating again. Use the Cloud Control Fast-Start Failover wizard or the DGMGRL ENABLE FAST_START FAILOVER command to enable fast-start failover. Automatic failover is optional and can be enabled or disabled on your Autonomous Container Databases with Autonomous Data Guard. DNS CNAME) that always resolves to the primary. We'll start with switchovers. The word manual is used to contrast this type of failover with a fast-start failover (described in Fast-Start Failover). Failover:- In case of worst situation with data guard primary database, or not available for production than we can activated standby database as a primary production database. On the Oracle Data Guard Overview page, click Database must be reinstated. For example, if the old standby was a physical or snapshot standby, then the old primary must be re-created as a physical standby. multiple, inexpensive servers is the basis for the failover and other fault-tolerance features that RAC provides. Remote login is required, along with a password file, to allow the databases in a Data Guard configuration to connect to each other. occur. irrespective of its content, indicates that the script executed successfully. become the master observer. Simply use DISABLE FAST_START FAILOVER. Oracle Data Guard provides the ability to create and maintain Standby databases at one or more sites These protect Oracle databases from database and server failures as well as site disasters Failover to one of the alternate sites can be set to happen automatically (fast-start failover) or manually if the primary database is not usable By default, both files are stored in $ORACLE_HOME/dbs. Flashback Database is a continuous data protection (CDP) solution integrated with the Oracle Database. Provides an automatic failover