Role Management Services
In a Data Guard configuration, a database operates in one of two mutually exclusive roles:
1. Primary role
2. Standby role(physical, Logical, Snapshot subtype)
You can use role management services to change the primary and standby roles dynamically as a planned transition called a switchover operation, or as a result of a database failure through a failover operation. For example, you might perform a switchover operation to transition the primary database to the standby role and transition a standby database to the primary role to perform routine maintenance tasks.
Role Transitions: Switchover and Failover
You can use the switchover feature to switch the role of the primary database to one of the available standby databases. The chosen standby database becomes the primary database, and the original primary database then becomes a standby database. There is no need to re-create any of the databases involved in the switchover operation. There is no data divergence between the original and new primary databases after the successful completion of the switchover.
You invoke a failover operation when a failure occurs on the primary database and there is no possibility of recovering the primary database in a timely manner. During a failover operation, the standby database assumes the primary database role. You invoke the failover operation on the standby database that you want to failover to the primary role.
A switchover operation transitions the primary database to the standby role and transitions the standby database to the primary role, without resetting the online redo logs of the new primary database.
The primary database at the start of a switchover operation will need to be shut down and restarted. The physical standby database is not shut down and restarted during a switchover. If the physical standby database is in the Active Data Guard mode, it is closed for the transition and then opened again after the switchover completes, but it is never totally shut down to require a restart.
If the switchover operation involves a logical standby database, there is no need to shut down and restart either the primary database or any of the standby databases. Logical standby databases do not need to be shut down and restarted.
As an example, suppose that the primary database is located in San Francisco and the physical standby database is located in Boston. Switchovers are started only on the primary database and completed on the target standby database. You can be connected to any database in the configuration through DGMGRL to execute the SWITCHOVER command.
After the switchover is completed, each database has the role opposite to the one that it had before the switchover. In this example, Boston is now the primary database and San Francisco is the standby database.
Because Data Guard does not automatically switch over sessions from one database to the other, active sessions for each system need to reconnect. See the lesson titled “Enhanced Client Connectivity in a Data Guard Environment” for information about configuring automatic methods to reconnect sessions.
Performing a Switchover by Using Enterprise Manager
When it is used for the switchover, Enterprise Manager:
a. Checks to ensure that the primary database and standby database are not currently in an error status condition and that broker management of the primary database is enabled and online
b. Automatically closes any active sessions connected to the primary database during the switchover
c. First changes the primary database to the standby role, and then changes the standby database to the primary role
d. Opens the target database if it is a mounted physical standby database and restarts the former primary database.
To initiate a switchover by using Enterprise Manager:
- On the Data Guard page, select the standby database that you want to become the primary database.
- Click Switchover. A credentials page may appear if you have not logged in to the standby database. The Data Guard Switchover Confirmation page is displayed
- Click the Browse Primary Database Sessions link to view active sessions.
- Click Yes to continue with the switchover, or click No to cancel.You cannot cancel the switchover operation after it begins.
The Data Guard Switchover Processing page displays the progress of the switchover operation as it:
- Switches roles between the primary and standby databases (If the switchover target is a physical standby database and mounted, it is opened without restarting. The former primary database is restarted.)
- Waits for the Data Guard broker to complete the initialization tasks required to switch the database roles
You can view the database alert log of the primary and standby databases by clicking the respective “View alert log” links. A new browser window opens with the content of the alert log. After the switchover operation is complete, you are returned to the Data Guard page.
Validating Databases for Switchover by Using DGMGRL
The VALIDATE DATABASE command performs a comprehensive set of database checks prior to a role change. The checks use the information available in various Oracle Data Guard views as well as the Automatic Diagnostic Repository. The VALIDATE DATABASE command shows a brief summary of the database and reports any errors or warnings that were detected. VALIDATE DATABASE VERBOSE shows everything in the brief summary plus all items that were validated. The VALIDATE DATABASE command should be performed against both the primary database and the standby database prior to performing a switchover. An example of verbose output against a physical standby database is as follows:
DGMGRL> validate database verbose london Database Role: Physical standby database Primary Database: boston Ready for Switchover: Yes Ready for Failover: Yes (Primary Running) Capacity Information: Database Instances Threads boston 1 1 london 1 1 Temporary Tablespace File Information: boston TEMP Files: 3 london TEMP Files: 3 Flashback Database Status: boston: Off london: Off Data file Online Move in Progress: boston: No london: No Standby Apply-Related Information: Apply State: Running Apply Lag: 0 seconds Apply Delay: 0 minutes Transport-Related Information: Transport On: Yes Gap Status: No Gap Transport Lag: 0 seconds Transport Status: Success Log Files Cleared: boston Standby Redo Log Files: Cleared london Online Redo Log Files: Cleared Current Log File Groups Configuration: Thread # Online Redo Log Groups Standby Redo Log Groups (boston) (london) 1 3 2 Future Log File Groups Configuration: Thread # Online Redo Log Groups Standby Redo Log Groups (london) (boston) 1 3 0 Current Configuration Log File Sizes: Thread # Smallest Online Redo Smallest Standby Redo Log File Size Log File Size (boston) (london) 1 50 MBytes 50 MBytes Apply-Related Property Settings: Property boston Value london Value DelayMins 0 0 ApplyParallel AUTO AUTO Transport-Related Property Settings: Property boston Value london Value LogXptMode ASYNC ASYNC Dependency DelayMins 0 0 Binding optional optional MaxFailure 0 0 MaxConnections 1 1 ReopenSecs 300 300 NetTimeout 30 30 RedoCompression DISABLE DISABLE LogShipping ON ON Automatic Diagnostic agnostic Repository Errors: Error boston london No logging operation NO NO Control file corruptions NO NO SRL Group Unavailable NO NO System data file missing NO NO System data file corrupted NO NO System data file offline NO NO User data file missing NO NO User data file corrupted NO NO User data file offline NO NO Block Corruptions found NO NO
Performing a Switchover by Using DGMGRL
After verifying the conditions required for executing a switchover, execute the SWITCHOVER command to perform the switchover operation.
DGMGRL> SWITCHOVER TO 'london'; Performing switchover NOW, please wait... Operation requires a connection to instance "london" on database "london" Connecting to instance "london"... Connected as SYSDG. New primary database "london" is opening... Operation requires startup of instance "boston" on database "boston" Starting instance "boston"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "london"
The Data Guard broker performs the following operations:
- Verifies that the primary database and target standby database are in the correct states
- Shuts down any instances as necessary
- Switches roles between the primary and standby databases
- Updates the broker configuration file with the new role information
- Restarts the new standby database (former primary) with Redo Apply running
- Opens the new primary database in read/writ Opens the new primary database in read/write mode and starts redo transport services
Preparing for a Switchover Using SQL
Before you execute the SWITCHOVER command, verify that standby redo log files are configured on the primary database. Standby redo log configuration should be identical on the primary database and on any physical standby databases. Even though the standby redo logs are not used when the database is in the primary role, configuring the standby redo logs on the primary database is recommended in preparation for an eventual switchover operation.
For switchovers involving a physical standby database, verify that the primary database is open and that Redo Apply is active on the standby database. For switchovers involving a logical standby database, verify both the primary and standby database instances are open and that SQL Apply is active.
The VALID FOR VALID_FOR clause of the LOG ARCHIVE DEST LOG_ARCHIVE_DEST_n parameters can be configured for both the primary database role and the standby database role. By creating separate destinations in advance for each role, the parameters would not need to be adjusted at the time of switchover.
Performing a Switchover by Using SQL
1. Verify that the target standby database is ready:
SQL> ALTER DATABASE SWITCHOVER TO 'london' VERIFY; Database altered.
2 Initiate the switchover on the primary database:
SQL> ALTER DATABASE SWITCHOVER TO 'london'; Database altered.
3. Open the new primary database.
4. Mount the new physical standby database.
5. Start Redo Apply on the new physical standby database.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; Database altered.
When not using the Data Guard broker, a switchover will require multiple commands to be issued. Each database involved in the switchover will have to be started appropriately (MOUNT for standby database, OPEN READ WRITE for primary databases) by making connections to each instance separately. If the parameter file or server parameter file was not created considering that a role change would take place, the parameters may need to be adjusted accordingly.
Considerations When Performing a Switchover to a Logical Standby Database
- Unlike a switchover to a physical standby database, a switchover to a logical standby database does not require a shutdown of the primary database.
- If you are switching over to a logical standby database, you do not need to terminate applications that are connected to the current primary database or to the logical standby database, because neither database is shut down during the switchover operation. However, because sessions on the old primary database may fail after the switchover operation is completed and the database guard is turned on, you should terminate such open sessions now. The database guard prevents users from making changes in the logical standby database.
- If you switch over to a logical standby database be aware that you may not have all of If you switch over to a logical standby database, be aware that you may not have all of the data that was in your primary database if the logical standby database is only a subset of the primary database.
- A switchover to a logical standby database invalidates and disables all physical and snapshot standby databases in the configuration. You must re-create the physical standby databases from a backup of the new primary database before you can reenable them.
Situations That Prevent a Switchover
You cannot perform a switchover if:
- Archived redo log files are unavailable: If there is a gap in the archived redo log files on the standby database, you cannot switch over to that standby database
- Point-in-time recovery is required: When you perform a switchover to a standby database, you always switch over to the current state of the primary database. You cannot switch over to a time in the past
- The primary database is not open and cannot be opened: A switchover is initiated on the primary database while it is in the open state. If you cannot open the primary database, a switchover is not possible
You invoke a failover operation when a failure occurs on the primary database and there is no possibility of recovering the primary database in a timely manner. During a failover operation, the primary database is disabled from the Data Guard environment and a standby database assumes the primary database role. Failing over to a standby database is a one-way operation. You cannot “fallback” and return the database to its former role as a standby database. Because of this, you should invoke a failover operation only in an emergency.
It is not always necessary to fail over to the standby database. In some cases, recovery of the primary database may be faster. Most failures can be resolved at a primary database in a reasonable amount of time.
In a failover operation:
- The original primary database is presumed to be lost. (If you want, you can reinstate or re-create the original primary database as a new standby database. You may then initiate a switchover operation compared to a failover operation to return the databases to their original roles.)
- Standby databases that are online at the time of the failover operation, but are not involved in the role transition, y do not need to be shut down and restarted unless they were ahead of the failover target due to differences in apply lag situations. In that case, they may need to be flashed back to the point the standby became a primary or recreated.
Types of Failovers
Manual failover can be invoked through Enterprise Manager, DGMGRL, or SQL. There are two types of manual failover:
- Complete: The maximum amount of redo data for the protection mode is recovered. In this type of failover, the broker avoids disabling any standby databases that are not the failover target. Complete failover is the default and recommended type of failover.
- Immediate: No additional redo data is applied to the standby database after the failover is invoked. This is the fastest type of failover. After an immediate failover, you must recreate or reinstate the original primary database and all standby databases that were not a target of the failover.
You can configure fast-start failover so that the broker automatically fails over to a chosen standby database in the event of the loss of the primary database.
During a failover operation, a standby database transitions to the primary role and the old primary database is rendered unable to participate in the configuration. Depending on the protection mode under which the old primary database was operating before the failover there may be some or no data loss during a failover.
A failover is typically used only when a primary database becomes incapacitated and there is no possibility of performing a switchover or successfully repairing the primary database in a reasonable amount of time.
The specific actions that are performed during a failover vary, depending on:
- Whether a logical or physical standby database is involved in the failover operation
- The state of the configuration at the time of the failover
- The specific SQL commands that are used to initiate the failover
Performing a Failover by Using Enterprise Manager
Perform a failover only in the event of a software or system failure that results in the loss of the primary database. The failed primary database is disabled by the broker and must be reinstated or re-created. The standby database then assumes the primary database role.
To initiate a failover by using Enterprise Manager:
1. On the Data Guard page, select the standby database that you want to become the primary database.
2. Click Failover.
3. On the Data Guard Failover Confirmation page, specify the type of failover that you want to perform:
- Complete: All available redo is applied on the standby database. Oracle Corporation recommends that you specify this type of failover.
- Immediate: No additional data is applied on the standby database, resulting in a data-loss failover. An immediate failover should be used only when a complete failover is not possible.
4. Select the failover option, and click Yes to confirm the failover operation.
After you click Yes, the Failover Processing page displays the progress of the failover operation. You cannot cancel this operation after it begins.
Performing a Failover to a Physical Standby Database
During the failover operation, the selected standby database transitions into the primary role. The failover target (a physical standby database) is restarted. When the operation finishes, the Data Guard Overview page reflects the updated configuration.
After a complete or immediate failover, the primary database and some standby databases may need to be reinstated or re-created. To reinstate the database, click the “Database must be reinstated” link. Then click Reinstate on the General Properties page. Enterprise Manager reinstates the database as a standby database to the new primary database.
Performing a Failover to a Logical Standby Database
When you perform a failover to a logical standby database, any physical standby databases in the configuration are permanently disabled after the failover and are no longer usable. These databases must be re-created from the new primary database.
Performing a Manual Failover by Using DGMGRL
1. Execute the FAILOVER command to initiate the failover operation to the standby database:
DGMGRL> FAILOVER TO 'london' [IMMEDIATE];
2.Reset the protection mode (if necessary).
3. Reinstate or re-create the former primary database to serve as a standby database in the configuration.
4. Reinstate or re-create other disabled standby databases in the configuration.
After determining that the primary database cannot be recovered in a timely manner, execute the FAILOVER command to perform the failover operation.
If you specify the IMMEDIATE option, no attempt is made to apply any unapplied redo that If you specify the IMMEDIATE option, no attempt is made to apply any unapplied redo that has been received.
The Data Guard broker performs the following operations for a complete failover:
1. Verifies that the target standby database is enabled.
2. Stops Redo Apply after all unapplied redo data is applied to the target standby database.
3. Transitions the target standby database to the primary database role by:
- Opening the new primary database in read/write mode Opening the new primary database in read/write mode.
- Determining whether any standby databases need to be reinstated or recreated.
- Starting redo transport services.
For an immediate failover, the broker does not wait for all available redo data to be applied (as described in step 2).
Reenabling Disabled Databases by Using DGMGRL
After a failover, you may need to reinstate or re-create databases in your configuration.If a database can be reinstated, the database has the following status after a complete failover:
ORA-16661: the standby database needs to be reinstated
To reinstate the database:
1. Start the database instance and mount the database.
2. In oke DGMGRL and connect to the ne primar database Invoke DGMGRL and connect to the new primary database.
3. Use the REINSTATE DATABASE DGMGRL command to reinstate the database.
DGMGRL> REINSTATE DATABASE boston;
If a database must be re-created, it has the following status after the failover:
ORA-16795: the standby database needs to be re-created
You must re-create the standby database from a copy of the primary database and then reenable it by using the ENABLE DATABASE DGMGRL command.
DGMGRL> ENABLE DATABASE boston;