This is an excerpt from the bestselling book
Oracle Grid & Real Application Clusters. To get immediate
access to the code depot of working RAC scripts, buy it
directly from the publisher and save more than 30%.
As noted earlier, fail-over (FO)
database clusters are implemented by many enterprises to meet their
high availability requirement. In this method, when there is a
failure on the primary node, the database instance running on the
failed node fails over to a backup node, in other words, it restarts
the database instance on the surviving node. However, the behavior
of a typical Parallel database cluster such as Oracle RAC is much
different. An Oracle RAC instance is not failed over, but causes the
reconfiguration of resources from the failed instance to the
non-failed instance(s) to take place.
This section will explore the
fail over database cluster functionality and various components such
as resources, resource groups and failover mechanisms.
Resources, Resource Types
Resources are hardware or
software entities, such as disks, network interface cards (NIC), IP
addresses, applications and database instances controlled by cluster
software. Controlling a resource means bringing it online
(starting), taking it offline (stopping) as well as monitoring the
health or status of the resource.
Depending on the type of
resource, the clustering software, through a script or an agent,
controls the status by starting and stopping activities. For
example, mounting involves starting a file system resource. Starting
IP resource involves configuration of the IP address on a network
interface card. Monitoring a resource means testing it to determine
if it is online or offline. How Cluster Software monitors a resource
is also specific to the resource type. For example, a file system
resource tests as online if mounted, and an IP address tests as
online if configured.
A resource group is a set of
resources working together to provide application services to
clients. A resource group is sometimes called a service group or a
package. Different cluster vendors call this by different names.
For example, as shown in Figure
3.7, a database resource group might consist of:
* Disk groups on which the
physical storage data volumes are located.
* Volumes built in the disk
* A file system using the
* Network interface card or
* One or more IP addresses
associated with the network card(s).
* A Listener Process.
* Database Instance.
A cluster software script or
agent executes operations on resources, including starting,
stopping, restarting and monitoring at the resource group level.
Resource group operations initiate administrative operations for all
resources within the group. For example, when a Resource group is
brought online, all the resources within the group are brought
online. When failover occurs, resources never fail-over individually
rather the entire resource group fails. Thus, the resource is the
unit of failover. If there is more than one group defined on a
server, one group may fail-over without affecting the other group(s)
on the server.
Figure 3.7: Cluster Resource
Group and Resources
From a cluster standpoint, there
are two significant aspects to this view of an application resource
group as a collection of resources:
* If a Resource group is to run
on a particular server, all of the resources it requires
must be available to the server.
* The resources comprising a
resource group have interdependencies; that is, some resources
(e.g., volumes) must be operational before other resources (e.g.,
the file system) can be made operational.