Database Reference
In-Depth Information
Parallelism in RAC
Enforcing parallelism can sometimes produce fruitful results, including enhancing the performance of SQL queries,
scaling up typical database manageability activities, and accelerating RMAN backup and recovery operations. In
this section, we discuss the significance of parallelism and exactly how it helps RMAN backup, restore, and recovery
operations in a RAC database.
When a database backup or restore operation is pioneered with multiple channels, Oracle determines and
sets the degree of parallelism based on the number of allocated channels for that job; thus, any restore or recovery
command (applying incremental backups) will span a corresponding number of slave processes to get the job done
quickly. Moreover, for media recovery tasks, such as applying archive logs, Oracle sets the parallelism automatically
based on the number of CPU resources on the node. In contrast, the PARALLEL hint with RECOVER statement will
limit and overwrite the default degree of parallelism. Last but not least, when there are a huge number of archive logs
to be applied as part of the recovery, parallelism indeed helps speed up the recovery time.
There have been some bugs reported of late with regards to parallel media recovery due to a few OS-related and
storage-related issues. These can be avoided by disabling parallelism by specifying NOPARALLEL in conjunction with
the RECOVER command.
Instance/Crash Recovery in RAC
A recovery operation on an Oracle database can be classified into two phases: media and instance/crash recovery.
A database instance or crash recovery is needed when an instance starts up after an abnormal stop. Typically, when
an instance fails or ends abruptly, it leaves the data files in an inconsistent state and also sets the current online redo
group flag in an open state. In a RAC database, when one or more instances fail, the surviving instance does the
instance recovery on behalf of the failed instances. When all instances of a RAC database fail, the instance that comes
up first does the crash recovery on behalf of other instances. An instance recovery is automatically done by the Oracle
System Monitor (SMON) background process without intervention from the DBA.
The prime objective of an instance/crash recovery is to ensure database consistency right after an instance
failure. The SMON process in that context reads the online redo logs and applies the redo changes to the appropriate
data blocks into their respective data files. An instance/crash recovery is done in two phases: rolling forward and
rolling back. During the rolling-forward phase, all committed transactions (data blocks) that are not written yet to the
concerned data files will be applied to the proper data files. In the rolling-back phase, all uncommitted transactions
occurring before the instance crash will be rolled back, reading the undo segments to guarantee database consistency.
Instance Recovery
Though instance recovery mechanisms remain identical in nonclustered and clustered environments, the way that
instance/crash recovery steps are carried out in a RAC database is slightly dissimilar from single-instance database
instance recovery mechanics.
Contrary to a stand-alone database, when a dead (failed) instance is detected by a surviving instance in a
RAC database, the SMON of the surviving instance initiates and does the instance recovery for the failed instance.
Likewise, when multiple instances of a RAC database fail, even if the failure is of all instances except one, the surviving
instance is responsible to perform recovery steps for all the failed instances. Figure
8-5
illustrates an instance recovery
mechanism in RAC by a surviving node.
