Oracle 12c New Features - Expert Consolidation in Oracle Database 12c - page 40

involve restarting the middle-tier since it was never written to deal with loss of database connectivity in mind. If such
an interruption is not possible then you need to become more resourceful and invest in the previously mentioned
Real Application Cluster. The active-active configuration allows the application to continue despite the fact that
an instance was lost although there might be a brief period where the system seems to “hang” due to resource
remastering. Of course, RAC cannot prevent you from a brown-out in the data center: if all the servers go down so will
your RAC database and you might have to invoke your disaster recovery scenario.
Since not every database administrator is familiar with RAC and the supporting technology the following sections
will introduce the most important aspects you need to know before you can appreciate the 12c new features for RAC.
Please note that virtualization and active/passive clusters will be explained in much more depth in Chapter 4.

Brief Introduction to Real Application Clusters
Oracle RAC is a cost option on top of Oracle Enterprise Edition. Using a shared-everything approach each database
instance “sees” all the changes made by its peers. Operating the database on multiple instances offers resilience
and more fault-tolerance compared to single instance deployments, if the applications are appropriately written
and tested. RAC pays tribute to the fact that many enterprise deployments moved from what accountants consider
expensive hardware to industry standard equipment. These enterprise deployments have often been on hardware that
supported extensive Reliability, Availability and Serviceability (RAS) features built-in. Although hugely beneficial to
the stability of the platform, these features come at a cost. Although RAS features exist in the high-end x86-64 platform
as well to a degree, a server failure can still happen with the previously mentioned problems associated with it. The
RAC value proposition includes:

• High Availability: thanks to the multi-instance database a server crash can be mitigated by

cleverly architected applications.

• Scalability: a Real Application Cluster can be extended should the need for new processing

power arise.

• Manageability: Multiple databases can be consolidated into a Real Application Cluster.

• Reduced Cost of Ownership: Combining Pluggable Databases and RAC can potentially reduce

the number of database servers, cutting cost for electricity, cooling, and real estate in the data
center.

From a technical point of view RAC is based on Oracle Grid Infrastructure. Grid Infrastructure combines Oracle's
cluster-aware logical volume manager, named Automatic Storage Management (ASM) with a high-availability
framework-Oracle Clusterware. Oracle Clusterware serves one main purpose: to hide the fact that multiple physical
machines are connected to form a cluster from the user. As such Clusterware performs all tasks you would expect
from a cluster framework:

• Cluster membership management: Every cluster framework must manage which hosts

are considered healthy members of the cluster. Under no circumstances must the cluster
find itself in a split-brain situation. In such a catastrophic state communication between
cluster members is interrupted while the cluster nodes are still running. Adhering to its
programming, the cluster software in each of the cluster halves will try to fail over resources of
the nodes it considers crashed. The danger of data corruption looms here: if the application
communicates with effectively unsynchronized cluster halves, different data can be written to
disk. Oracle Clusterware uses a network and disk heartbeat to prevent a split brain scenario.

• Fencing: If Clusterware detects that a node or set of nodes in the cluster is unresponsive then it

will evict members from the cluster to prevent corruption. This process is called node fencing.
Beginning with Oracle 11.2 fencing has been greatly improved using the Intelligent Platform
Management Interface (IPMI) effectively allowing a cluster member to evict an unhealthy
member using a hardware command.