Duplicate configuration names in configuration definitions are not allowed. These 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. may allow the primary database to continue redo generation after The broker allows the failover to proceed as long as there are no errors for the standby database that you selected to participate in the failover. Neither the primary database nor the logical standby database needs to be restarted after the switchover completes. In the previous article, we have seen switching the role of Primary and standby database and failover Primary role to Standby database manually. The observer is perfectly satisfied if all of the redo it needs to meet your durability requirements has been received by the failover target. occurred to the target standby database prior to disabling fast-start Subdirectories within Use the SQL ALTER DATABASE MOVE DATAFILE command to rename or relocate an online data file on a physical standby that is a fast-start failover target if the standby is mounted, but not open. For example: Scenario 6: Enabling Fast-Start Failover and Starting the Observer. Verifies that the primary and the target standby databases are in the following states: The primary database is enabled and is in the TRANSPORT-ON state. This list contains some recommendations to obtain better performance when using fast-start failover. Unlike the primary / standby interconnect, where bandwidth and latency are determining performance factors, the observer requires very little network bandwidth and is not overly latency sensitive, allowing the it to be placed practically anywhere a reliable connection is available. (Note: 11.1.0.7 adds the StaticConnectIdentifier Broker database property to allow you to specify a different service name.) time specified by maximum configured configuration named ConfigurationSimpleName. The current primary database must have its LogXptMode property set accordingly and must have standby redo logs configured. Reset database properties related to Redo Apply services, such as DelayMins. Now it will return PRIMARY. Then set the configuration protection mode to maximum availability. This configuration property causes the former primary database to be automatically reinstated if a fast-start failover was initiated because the primary database was either isolated or had crashed. The behavior of the broker if the master observer fails depends on whether the broker configuration has one observer or multiple observers. That is, if the observer is connected to any instance in the Oracle RAC, all instances will show a value of YES. POTENTIAL DATA LOSS: Fast-start failover is enabled with some data loss. operation. This list describes conditions in which the broker cannot automatically reinstate the former primary database. Reinstate the former primary database as a new standby database. Then, on the Failover Confirmation page, click Yes to invoke the default Complete failover option. These conditions are described in the following table: Dictionary corruption of a critical database. There are many examples, and Ritesh Chhajer offers this example of doing a Data Guard switchover using dgmgrl: 1. When this property is set to NONE, the broker will disable all bystander standby databases without checking whether they have applied more redo data than the new primary database. You can specify particular conditions for which a fast-start failover should occur using either Cloud Control or the DGMGRL ENABLE FAST_START FAILOVER CONDITION and DISABLE FAST_START FAILOVER CONDITION commands. After the failover completes, the former primary database is automatically reinstated as a standby database when a connection to it is reestablished, if the FastStartFailoverAutoReinstate configuration property is set to TRUE. As a result, there is no guarantee that the observer will not perform a fast-start failover to the target standby database if the observer determines that conditions warrant a failover. To stop a specific observer when there are multiple registered observers running, issue the following command: You can log into DGMGRL from any machine to stop an observer. prolonged stall, either the observer or target standby database If you already have an FRA, you may need to increase its size in order to accommodate the Flashback Database files. Note the primary and target standby must have connectivity for this command to complete successfully. pre-callout configuration script and post-callout configuration script. Switching over to a logical standby database results in the snapshot and physical standby databases in the broker configuration being disabled by the broker, making these databases no longer viable as standby databases. In the event of a If the status is SUCCESS, you're ready to start testing role transitions. Valid values are >= 100. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role. Since the observer is a specialized instance of a dgmgrl session, the observer host should be installed with either the Oracle Client Administrator software or the full Oracle Database software stack. The broker continuously monitors for all sessions that are connected However, if the standby has had contact from the primary within the period of time specified by the FastStartFailoverThreshold property, the standby prevents the failover attempt. The most common problems are mismatched Data Guard protection modes and LogXptMode properties and forgetting to enable Flashback Database on the primary or standby. What is true about data guard set up with fast-start failover (FSFO) in Oracle Cloud Infrastructure (OCI)? The original primary database can now be configured as a standby. present, you must start the observer manually using the following (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. observer as a foreground process. If only a file name is directory by this environment variable does not exist, or the $DG_ADMIN Determining a Database's Readiness to Change Roles. is only possible when the configured data loss guarantee can be After setting local_listener, register the database with the listener and verify the services have been registered. A switchover is a role reversal between the primary database and one of its standby databases. 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. 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. 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. Although redo transfer is synchronous, Maximum Availability mode allows the primary to remain available if the standby database becomes unavailable for any reason (e.g. The real test of the configuration is a successful role transition in both directions with both switchover and FSFO failover. Each observer has its own log file. If the target standby database is ready for failover, then the master observer immediately directs the target standby database to fail over to the primary database role. property. The FS_FAILOVER_STATUS column in the V$DATABASE view for the target standby database displays a reason why fast-start failover cannot occur. Careful consideration should be given before enabling fast-start failover for either of these conditions because doing so will supersede availability options provided by Oracle Clusterware. Use the EMCLI verb dg_configure_observers. Issue the following SRVCTL commands: Now the correct services are running on the correct databases. Therefore, the primary database can continue processing transactions, even if the target standby database fails. 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. In case of primary database failure, you will need to perform failover to transition the standby database to the primary role. crash, data in this file can be used to restart the observer to the 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. This article - the seventh in this ongoing . DG_ADMIN environment variable is not set, the files are stored in The default session. Log in as a test user and make some changes that won't impact other parts of the system. The group of broker configurations to be managed is declared in the observer configuration file. DNS CNAME) that always resolves to the primary. A failover to a logical standby database requires that all physical and snapshot standby databases be re-created from a copy of the new primary database after the failover completes. from another DGMGRL session. The example uses 10 seconds. If fast-start failover is enabled you can still perform a switchover or a manual failover as long as certain conditions are met. It is possible to manually perform a completer failover to a standby database that receives redo data from a far sync instance. receives redo data from a far sync instance. If the broker performs a switchover or failover, then it starts the service SALESRW or SALESRO based on the current role of the database. A number of prerequisites must be met on the primary in order to use Fast-Start Failover. These are the guidelines for choosing a target standby database. 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. created under this directory by DGMGRL will also have the same permissions. Failovers become routine. See the Oracle Reference and Data Guard Administrator guides for your release for details. With increased latency comes decreased throughput; however, in some cases the difference in throughput may be made up by increasing parallelism. Then the STOP OBSERVER command can be issued successfully on the former master observer. For example, if the limit specified is 30 seconds (the default), FSFO guarantees that all transactions that committed prior to 30 seconds ago are preserved during failover. This action may result in two databases in the configuration simultaneously assuming the primary database role. In the following example, a service named sales is configured to be active in the PHYSICAL_STANDBY role on the primary database NORTH. Always try to perform a complete failover first unless redo apply has stopped at the failover target due to an ORA-752 or ORA-600 [3020] error. Oracle 12c-Step by Step Manual Data Guard Failover. Immediate Failovers in Configurations Using Cascaded Standbys. 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. The Oracle Database 11g observer can make use of specific credentials, allowing the same wallet to be used for multiple observers with different SYS passwords. It is then configured to be active in the PHYSICAL_STANDBY role on the physical standby database SOUTH. Theoretically, this method can be used when a data guard failover occurred between the primary and standby database, but not a switchover. It may be possible to convert the old Primary into a Standby database now instead of having to do a time consuming duplicate again. The default value is 30 seconds. Getting the Oracle Net configuration right is one of the key factors in a successful FSFO deployment.