Reinstate the former primary database as a new standby database.
Data Guard Physical Standby Setup in Oracle Database 11g Release 2 This guide uses the naming convention of appending an underscore followed by a letter to the db_name to create the db_unique_name. observer immediately begins monitoring the status and connections to DG_ADMIN environment variable is not set, the files are stored in To see Manual Switch Over Manual SwitchOver in Oracle To see Manual Fail Over Manual Failover in Data Guard With Oracle Data Guard [] LinkedIn:https://www.linkedin.com/in/hari-prasath-aa65bb19/ The selected standby database that will be the fast-start failover target must receive redo directly from the primary database. post-callout script, and pre-callout success file for the broker If a single-instance primary database (either Oracle RAC or non-Oracle RAC), or if all instances of an Oracle RAC primary database are shut down with the ABORT option, the observer attempts a fast-start failover. Another good test is to simulate network failures that leave the primary up, but isolated from the failover target standby and the observer. Step:5Bounce your database and verify database name its open mode and its role. (This is useful because the name defined in the metadata may contain whitespace and international characters, which the observer configuration file does not allow.). the SYSDG or SYSDBA privilege. RMAN also copies the spfile and password files and you can change the values for individual parameters. When performing a failover in a configuration whose standbys are all of the same type, choose the standby database that has the smallest transport lag. In case of primary database failure, you will need to perform failover to transition the standby database to the primary role. The foundation of FSFO is Data Guard - a primary and at least one standby. callout configuration file. Enabling fast-start failover does not trigger a failover. The broker never automatically reinstates the former primary database if a fast-start failover was initiated because a user configuration condition was detected or was requested by an application calling the DBMS_DG.INITIATE_FS_FAILOVER function. 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. The failover was to a logical standby database. Examine the Broker configuration by logging into dgmgrl on the new primary. 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. on particular instances based on the service configuration. The standby VM (myVM2) has the Oracle software installed only. Set this property for the primary and target standby database if you want the observer to use a different connect identifier than that used to ship redo data (that is, the connect identifier specified by the DGConnectIdentifier property). You can perform a manual failover even if fast-start failover is enabled. Otherwise, they must be re-created from a copy of the new primary database. A normal shutdown uses SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL. In this case, the FS_FAILOVER_STATUS and FS_FAILOVER_OBSERVER_PRESENT columns will appear as shown in the following table and fast-start failover will not occur: Oracle Database Reference for more information about the V$DATABASE view. DG BrokerDG BrokerData Guard BrokerOracleDGRMAN Duplicate . all of the same type (all physical or all logical standby databases), choose the standby We'll start it interactively for now to verify that everything's working. The new ConfigurationWideServiceName configuration property can be used to simplify setting up this connect identifier. The default value is 30 seconds and the lowest possible value is 5 seconds. /home1/dataguard/config_NorthSales/callout/fsfocallout.ora. If it reconnects to the primary database before the standby agrees to fail over, then the master observer will stop attempting to initiate a fast-start failover. ConfigurationSimpleName is created. If the protection mode was at maximum availability or maximum performance, it remains unchanged. Verifies that the target standby database is enabled. If you re-create the old primary database, it must be created as the standby type of the old standby database. 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. configuration named ConfigurationSimpleName. under the $DG_ADMIN directory.
Data Guard switchover with dgmgrl - dba-oracle.com You can use the maximum protection, maximum availability, or maximum This is Whereas a switchover to a logical standby database will invalidate and disable all of the physical and snapshot standby databases in the configuration. To proceed, you must first disable fast-start failover using the FORCE option, and then perform a manual failover. It will also alert you to databases that have had Flashback Database disabled at some point after FSFO was enabled. Use the Cloud Control Fast-Start Failover wizard or the DGMGRL ENABLE FAST_START FAILOVER command to enable fast-start failover. The physical and snapshot standby databases will have to be re-created from a copy of the new primary database. Specifying Preferred Observers Based on Current Primary. 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. Opens the new primary database in read/write mode. using the same SYS credentials you used when you connected to the In this case, no attempt is made to transmit any unsent redo from the far sync instance to the target physical standby prior to converting the physical standby into a primary database. 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). To maintain a viable disaster-recovery solution in the event of another disaster, you may need to perform additional steps. 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. The broker continuously monitors for all sessions that are connected 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. In such a case, no attempt is made to transmit any unsent redo from the cascader to the terminal standby. 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). If you expect the network to be disconnected for a long time and 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. During failover, bystanders "follow" the primary by default, flashing back and reapplying redo from the new primary as necessary. Immediately after issuing command in step 2, shut down and restart the standby instance STAN: The Appendix provides information oncreating a simple wrapper script to start the observer as a background process. 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. Oracle Database PL/SQL Packages and Types Reference for more information about the DBMS_DG package. The command SHOW OBSERVER provides detailed information about registered observers. FastStartFailoverAutoReinstate is set to FALSE, Another failover or switchover occurred after the fast-start failover completed but before the former primary database restarted, The master observer cannot connect to the former primary database, The former primary database cannot connect to the new primary database, The former primary database and the new primary database are not configured in the same fast-start failover environment, The former primary database was disabled because of a manual failover when fast-start failover was disabled. In The following sections provide information about managing observers: How the Observer Maintains Fast-Start Failover Configuration Information, Patching an Environment When the Observer Is Running and Fast-start Failover Is Enabled. Whenever possible, you should switch over to a physical standby database: If the switchover transitions a physical standby database to the primary role, then: The original primary database will be switched to a physical standby role. Fast-start failover will not occur unless all instances comprising the Oracle RAC primary database are perceived to have failed. Thus, the validity of the values of these properties is not verified until after the switchover. The walkthrough begins with a single database that will become the primary of a Data Guard configuration. Input commands are shown in shaded boxes in normal text. Here's a one-liner observer startup for *nix. A trigger on the DB_ROLE_CHANGE system event can be used to update the naming service and, with the proper client cache TTL settings, clients can connect to the new primary very quickly. The minimum value is 100 milliseconds. The services include switchover, switchback and failover. Any database that was disabled while multiple role changes were performed cannot be reinstated. required permissions, fast-start failover callouts will fail. VALIDATE 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. A running observer will follow the primary automatically after a role transition, but a newly (re)started observer won't start if the initial connection is to a down database or one with an out of date or corrupted Broker config file. Disable fast-start failover using the DGMGRL DISABLE FAST_START FAILOVER command. Oracle Data Guard work on two database roles Primary and Standby. This action will result in loss of data and the possibility of two databases in the configuration simultaneously assuming the primary database role. See START OBSERVER IN BACKGROUND for more information 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. This They must be re-created before they can serve as standby to the new primary database. 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.". This list describes conditions in which the broker cannot automatically reinstate the former primary database. present, you must start the observer manually using the following 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. Writing the wrapper itself and the means to determine when to execute it are up to you. The subdirectories that DGMGRL creates under this directory will also have the If there is more than one registered observer, then this command returns an error; a name is required if there is more than one observer. Once the observer has initiated a fast-start failover, the primary database shuts down automatically. Dataguard PDB level failover support for Multitenant Oracle 19c gets enabled and then begins monitoring. When both databases have been restarted, you may restart the observer. You can switch back to the original Primary database later by performing another switch over. Reinstatement restores high availability to the broker configuration so that, in the event of a failure of the new primary database, another fast-start failover can occur. During a complete failover, the broker performs the failover steps described in How the Broker Performs a Complete Failover Operation. See Reenabling Disabled Databases After a Role Change. 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. FastStartFailoverLagLimit configuration property is set to zero) or These scripts must be in the same directory as the In this case, disable fast-start failover using the FORCE option on the target standby database. Look for the desired data in the RAM. ZERO DATA LOSS: Fast-start failover is enabled with zero data loss. To start a switchover using Cloud Control, select the standby database that you want to change to the primary role and click Switchover. fast-start failover succeeds, if a post-callout script is specified in the fast-start All standbys other than the failover target are considered bystanders (v$database.fs_failover_status = 'BYSTANDER'). If you want the broker to skip this viability check of bystander standby databases during a complete failover, thus decreasing the overall failover time, set the BystandersFollowRoleChange configuration property to NONE. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role. instructions for the DGMGRL command-line interface. Now test FSFO failover back to the original primary. SQL> startup ORACLE instance started. There can be up to four Use broker configuration properties to set the time taken to detect a Do not attempt to reinstate the old primary database if an ORA-752 or ORA-600 [3020] error has occurred at the failover target. 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. For Maximum Availability environments, change this to synchronous. 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. PRIM>connect /@PRIM as sysdba $DG_ADMIN directory. 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 the database is managed by Oracle Clusterware, broker does not open any of the In the following example commands, a service named PAYROLL is configured to be active in the PRIMARY role on the primary database NORTH. If Flashback Database history is insufficient, the observer will not be able to reinstate and you will have to manually reinstate from backup or by primary duplication. If fast-start failover is disabled, then manual failover may still be possible. 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). A far-sync instance cannot be used in maximum protection mode. You can specify STOP OBSERVER ALL to stop all observers registered in a broker configuration. This is because the -role qualifier is taken into account only by Data Guard broker, and at database startup. Table 6-2 FS_FAILOVER_STATUS Column of the V$DATABASE View. See the Oracle Maximum Availability Architecture technical briefs at: When setting the FastStartFailoverLagLimit configuration property, consider these tradeoffs between performance and potential data-loss: A low lag limit will minimize data loss but may impact the performance of the primary database. Once fast-start failover is enabled, the broker will ensure that fast-start failover Log in as a test user and make some changes that won't impact other parts of the system. See Oracle Data Guard Concepts and Administration for more information on using the ALTER SYSTEM FLUSH REDO statement. However, the event notifying a failover is only published for database services that have been configured to be active while the database is in the primary role on the new primary database. Without the credentials, Broker will complete the role transition, but will leave the databases in need of a manual restart. Many customers use Oracle Database deployed on Amazon Elastic Compute Cloud (Amazon EC2) to run their Oracle E-Business Suite applications. Use the callout configuration file and script In this case fast-start failover cannot occur because the databases are not ready to failover. The broker reinstates a failed primary database as a standby database of the same type (physical or logical standby database) as the old standby database. If no value is specified for the See Directing a Fast-Start Failover From an Application). The ObserverPingInterval Moorestown, New Jersey, United States. observers are registered, a directory named Even if you have successfully connected to a database server in the broker configuration using the CONNECT command, this command ignores the existing connection and uses the credentials stored in Oracle wallet. operation: Example 6-1 Fast-start Failover Configuration You can register up to four observers to monitor a single Data Guard broker configuration. Fast-Start Failover in Oracle 11g Data Guard - Database Journal Note the use of "/@" to login using the wallet. See the Cloud Control online help for more information. Restart the database to the mounted state, Use Cloud Control or DGMGRL to reinstate the database. The default name of the callout configuration file is Thus, the command-line prompt on the observer computer does not The OberverPingRetry property specifies the number of If an application has called this function and it has received a status of SUCCESS, then the master observer attempts a fast-start failover. Before a These conditions are described in the following table: Dictionary corruption of a critical database. Other logical standby bystander databases in the broker configuration will remain viable after the switchover. This allows for redundancy in your Data Guard observer setup as well. If the target is a snapshot standby database, the broker first converts the database to a physical standby database. 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. the location of the observer log file, and the location of the observer runtime data you need to make the primary database available, first confirm that a Being FSFO ready means that all conditions are met for a successful failover, including having a running observer and sufficient redo transmitted to the failover target to meet durability requirements. The FORCE option may be the preferred method for disabling 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. Start the Data Guard listener on both "a" and "b" hosts. Use Cloud Control or DGMGRL to perform either a complete (recommended) or an immediate failover. Staff support, hardware and software, security (both software and site), network connections, and bandwidth should be equivalent at both sites. Data Guard Broker Failover - DBA Genesis Support 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. PeopleSoft can be configured for Active Data Guard. 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. Ideally the primary, standby, and observer will be in geographically separate areas. about starting the observer as a background Metadata for the fuzzy snapshot is stored in the flashback log itself. Reenabling Disabled Databases After a Role Change describes how to restore their viability as standby databases. However, if you want the observer to reconnect to the primary database periodically as a means of testing the health of the network connection to the primary, then use the ObserverReconnect configuration property. Stopping a Specific Observer When There are Multiple Observers. time specified in the WAIT option. observer computer is returned to you so that you can continue to 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. 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). A fast-start failover occurred because a user-configurable condition was detected or was requested by an application by calling the DBMS_DG.INITIATE_FS_FAILOVER function. Broker maintains these parameters by issuing ALTER SYSTEM commands as appropriate during role transitions, database startup/shutdown, and other events. This list contains some recommendations to obtain better performance when using fast-start failover. Media Recovery - Once the restore is complete, recovery proceeds as a typical media recovery, applying redo from archived and online redologs and rolling back uncommitted changes with undo. 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.