Role Transition Best Practices

With proper planning and execution, Data Guard role transitions can effectively minimize downtime and ensure that the database environment is restored with minimal impact on the business. Whether using physical standby or logical standby databases, MAA testing has determined that switchover and failover times with Oracle Data Guard 10g release 2 have been reduced to seconds. This section describes best practices for both switchover and failover.

This section contains these topics:

■ Role Transition During Switchover

■ Role Transition During Failover

2.4.7.1 Role Transition During Switchover

A database switchover performed by Oracle Data Guard is a planned transition that includes a series of steps to switch roles between a standby database and a production database. Following a successful switchover operation, the standby database assumes the production role and the production database becomes a standby database. In a RAC environment, a switchover requires that only one instance be active for each database, production and standby.

At times the term switchback is also used within the scope of database role

management. A switchback operation is a subsequent switchover operation to return the roles to their original state.

Data Guard enables you to change these roles dynamically by:

■ Using Oracle Enterprise Manager, as described in Section 4.2.3.2.1, "Using Enterprise Manager to Perform a Data Guard Switchover" on page 4-20

■ Using the Oracle Data Guard Broker command-line interface

■ Issuing SQL statements, as described in Section 4.2.3.2.2, "Using SQL for Data Guard Switchover to a Physical Standby Database" and Section 4.2.3.2.3, "Using SQL for Data Guard Switchover to a Logical Standby Database" beginning on page 4-22

See Also: Oracle Database PL/SQL Packages and Types Reference and Oracle Data Guard Concepts and Administration for more information on the DBMS_LOGSTDBY PL/SQL package

2.4.7.1.1 Switchover Best Practices To optimize switchover processing, use the following best practices and see the Oracle Database 10g Release 2 Best Practices: Data Guard Switchover and Failover white paper available at

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_

10gR2_SwitchoverFailoverBestPractices.pdf:

■ For logical standby databases:

– See Oracle Database 10g Release 2 Best Practices: Data Guard SQL Apply at http://www.oracle.com/technology/deploy/availability/htdoc s/maa.htm to obtain an optimal SQL Apply rate.

– Verify the LogMiner Multiversioned Data Dictionary was received by the primary database by querying the SWITCHOVER_STATUS column of the V$DATABASE fixed view on the primary database. When the query returns the TO LOGICAL STANDBY value, you can proceed with the switchover. See the discussion about "Switchovers Involving a Logical Standby Database" in Oracle Data Guard Concepts and Administration

■ For physical standby databases:

– See Oracle Database 10g Release 1 Best Practices: Data Guard Redo Apply and Media Recovery at

http://www.oracle.com/technology/deploy/availability/htdoc s/maa.htm to obtain an optimal Redo Apply rate.

– When transitioning from read-only mode to Redo Apply (recovery) mode, restart the database.

■ Use real-time apply so that redo data is applied to the standby database as soon as it is received.

To enable real-time apply for a physical standby database, use the following SQL statement:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;

To enable real-time apply for a logical standby database, use the following SQL statement:

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

■ Enable Flashback Database so that if a failure occurs during the switchover, the process can be easily reversed.

2.4.7.2 Role Transition During Failover

Failover is the operation of taking the production database offline at one site and bringing one of the standby databases online as the new production database. A failover operation can be invoked when a catastrophic failure occurs on the production database, and there is no possibility of recovering the production database in a timely manner.

With Data Guard the process of failover can be completely automated using fast-start failover, or it can be user driven. Fast-start failover eliminates the uncertainty inherent

See Also: Oracle Data Guard Broker for information about using Enterprise Manager or the Data Guard broker command-line to perform database switchover

in a process that requires manual intervention. It automatically executes a zero data loss failover within seconds of an outage being detected.

Oracle recommends that you use fast-start failover. The initial MAA tests running Oracle Database 10g Release 2 (10.2) show that failovers performed using the Data Guard Broker and fast-start failover offer a significant improvement in availability.

Manual failover allows for a failover process where decisions are user driven. Manual failover can be accomplished by:

■ Issuing SQL statements, as described in Section 4.2.2.2.2, "Using SQL to Fail Over to a Physical Standby Database" on page 4-18

■ Using Oracle Enterprise Manager, as described in Section 4.2.2.2.1, "Using Enterprise Manager to Perform a Data Guard Failover" on page 4-15

■ Using the Oracle Data Guard Broker command-line interface (DGMGRL)

This section contains these topics:

■ Comparing Fast-Start Failover and Manual Failover

■ Fast-Start Failover Best Practices

■ Manual Failover Best Practices

2.4.7.2.1 Comparing Fast-Start Failover and Manual Failover Fast-start failover can be used only in a Data Guard Broker configuration. It can be configured only through

DGMGRL or the Data Guard management pages in Oracle Enterprise Manager.

Fast-start failover also requires that the redo transport services be configured for LGWR SYNC, and the Data Guard configuration should be in maximum availability mode to achieve the stated guarantee of zero data loss failover. In addition both the primary and standby databases must have Flashback Database enabled. When enabled, fast-start failover monitors the Data Guard configuration and initiates a failover automatically to the specified target standby database automatically, with no need for DBA intervention and with no loss of data.

The following conditions will trigger a fast-start failover:

■ Database instance failure (or last instance failure in a RAC configuration)

■ Shutdown abort (or shutdown abort of the last instance in a RAC configuration)

■ Datafiles taken offline due to I/O errors

■ Both the observer (fast-start failover monitoring process) and the standby database lose their network connection to the primary database, and the standby database confirms that it is in a synchronized state.

Following a fast-start failover, the old primary database is automatically reconfigured as a new standby database upon reconnection to the configuration. This enables Data

See Also: Oracle Database 10g Release 2 Best Practices: Data Guard Fast-Start Failover at

http://www.oracle.com/technology/deploy/availability /htdocs/maa.htm for a comprehensive review of Oracle failover best practices

See Also: Oracle Data Guard Broker for information about using Enterprise Manager or the Data Guard broker command-line for database failover

Guard to restore disaster protection in the configuration quickly and easily, returning the database to a protected state as soon as possible.

A Data Guard manual failover is a series of steps to convert a standby database into a production database. The standby database essentially assumes the role of production database. A Data Guard failover is accompanied by an application failover to fail over the users to the new primary database. After the failover, the former production database must be re-created as a new standby database to restore resiliency. The standby database can be quickly re-created by using Flashback Database. See Section 4.3.2, "Restoring a Standby Database After a Failover" on page 4-50.

2.4.7.2.2 Fast-Start Failover Best Practices The following are fast-start failover best practices:

■ Use real-time apply so that redo data is applied to the standby database as soon as it is received.

■ Enable Flashback Database to protect from logical failures.

■ Run the fast-start failover observer process on a host that is not located in the same data center as the primary or standby database.

Ideally, the observer should be run on a system that is equally distant from primary and standby databases. It should connect to the primary and standby databases using the same network as any end-user client. If the designated observer fails, Enterprise Manager can detect it and can be configured to automatically restart the observer. If unable to run at a third site the observer should be installed on the same network as the application.

■ If the standby database has been opened in read-only mode, then restart the database before starting Redo Apply.

■ Consider configuring multiple standby databases to maintain data protection following a failover.

■ Set the value of the FastStartFailoverThreshold property according to your configuration characteristics, as described in Table 2–3.

For any of the settings shown in Table 2–3, perform testing to ensure that the fast-start failover threshold is not so aggressive that it will induce false failovers, or so high it does not meet your failover requirements.

See Also: Oracle Data Guard Broker for more information on failover operations

Table 2–3 Minimum Recommended Settings for FastStartFailoverThreshold

Configuration Minimum Recommended Setting

Single instance primary, low latency, and a reliable network

15 seconds

Single instance primary and a high latency network over WAN

30 seconds

RAC primary Reconfiguration time + 30 seconds ¹

1 For configurations running Oracle Database software prior to Release 10.2.0.3, use a minimum of RAC miscount + reconfiguration time + 30 seconds

2.4.7.2.3 Manual Failover Best Practices A manual failover, which is user-driven, should be used only in case of an emergency and should be initiated due to an unplanned outage such as:

■ Site disaster that results in the primary database becoming unavailable

■ User errors that cannot be repaired in a timely fashion

■ Data failures, to include widespread corruption, which impacts the production application

A failover requires that the initial production database must be reinstated as a standby database to restore fault tolerance to your environment. The standby database can be quickly reinstated by using Flashback Database. See Section 4.3.2, "Restoring a Standby Database After a Failover" on page 4-50.

To optimize failover processing and to maintain high availability, use the following best practices:

■ Enable Flashback Database to reinstate databases after the failover operation has completed.

■ Use real-time apply in conjunction with Flashback Database to apply redo data to the standby database as soon as it is received, and to quickly rewind the database should user error or logical corruption be detected.

■ For logical standby databases, see Oracle Database 10g Release 2 Best Practices: Data Guard SQL Apply at

http://www.oracle.com/technology/deploy/availability/htdocs/m aa.htm to obtain an optimal SQL Apply rate.

■ For physical standby databases:

– See Oracle Database 10g Release 1 Best Practices: Data Guard Redo Apply and Media Recovery at

http://www.oracle.com/technology/deploy/availability/htdoc s/maa.htm.

– Go directly to the OPEN state from the MOUNTED state instead of restarting the standby database (as required in previous releases).

■ When transitioning from read-only mode to Redo Apply (recovery) mode, restart the database.