2.4 Configuring Oracle Database 11g with Oracle RAC

2.4.1 Understand the Instance Recovery Target and Optimize (if Required)

Instance recovery, which is the process of recovering the redo thread from the failed instance, is a critical component affecting availability. The availability of the database during instance recovery has greatly increased over the last few major releases of the Oracle Database.

When using Oracle RAC, the SMON process in one surviving instance performs instance recovery of the failed instance. This is different from crash recovery, which occurs when all instances accessing a database have failed. Crash recovery is the only type of recovery when an instance fails using a single-instance Oracle Database.

In both Oracle RAC and single-instance environments, checkpointing is the internal mechanism used to bound Mean Time To Recover (MTTR). Checkpointing is the process of writing dirty buffers from the buffer cache to disk. With more aggressive checkpointing, less redo is required for recovery after a failure. Although the objective is the same, the parameters and metrics used to tune MTTR are different in a single-instance environment versus an Oracle RAC environment.

In a single-instance environment, you can set the FAST_START_MTTR_TARGET initialization parameter to the number of seconds the crash recovery should take. Note that crash recovery time includes the time to startup, mount, recover, and open the database.

Oracle provides several ways to help you understand the MTTR target your system is currently achieving and what your potential MTTR target could be, given the I/O capacity. See the MAA white paper "Best Practices for Optimizing Availability During Unplanned Outages Using Oracle Clusterware and Oracle Real Application Clusters" for more information.

2.4.2 Maximize the Number of Processes Performing Transaction Recovery

The FAST_START_PARALLEL_ROLLBACK parameter determines how many processes are used for transaction recovery, which is done after redo application. Optimizing transaction recovery is important to ensure an efficient workload after an unplanned failure. As long as the system is not CPU bound, setting this parameter to HIGH is a best practice. This causes Oracle to use four times the CPU count (4 X cpu_count) parallel processes for transaction recovery. The default setting for this parameter is LOW, or two times the CPU count (2 X cpu_count). Set the parameter as follows:

ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK=HIGH SCOPE=BOTH;

By employing this database configuration best practice along with the one described in Section 2.4.3, "Ensure Asynchronous I/O Is Enabled"it is possible to achieve approximately a 20% increase in total availability at the database level.

2.4.3 Ensure Asynchronous I/O Is Enabled

Using asynchronous I/O is a best practice that is recommended for all Oracle Databases. See Section 2.2.1.8, "Set DISK_ASYNCH_IO" for guidelines.

2.4.4 Redundant Dedicated Connection Between the Nodes

Use redundant dedicated connections and sufficient bandwidth for public traffic, Oracle RAC interconnects, and I/O.

Separate dedicated channels on one fibre may be needed, or you can optionally configure Dense Wavelength Division Multiplexing (referred to as DWDM) to allow communication between the sites without using repeaters and to allow greater distances (greater than 10 km^Foot 6 ) between the sites. However, the disadvantage is that DWDM can be prohibitively expensive.