Oracle RAC

This section discusses Oracle RAC: its architecture, infrastructure requirements, and main
components.

Database Clustering Architecture

To achieve horizontal scalability or scale-out of a database, multiple database servers are
grouped together to form
a cluster infrastructure. These servers are linked by a private interconnect network and
work together as a single
virtual server that is capable of handling large application workloads. This cluster can be
easily expanded or shrunk by
adding or removing servers from the cluster to adapt to the dynamics of the workload.
This architecture is not limited
by the maximum capacity of a single server, as the vertical scalability (scale-up) method is.
There are two types of
clustering architecture:
Shared Nothing Architecture
•
Shared Everything Architecture
•
The shared nothing architecture is built on a group of independent servers with storage
attached to each server.
Each server carries a portion of the database. The workloads are also divided by this
group of servers so that each
server carries a predefined workload. Although this architecture can distribute the
workloads among multiple servers,
the distribution of the workloads and data among the servers is predefined. Adding or
removing a single server would
require a complete redesign and redeployment of the cluster.
For those applications where each node only needs to access a part of the database, with
very careful partitioning
of the database and workloads, this shared nothing architecture may work. If the data
partition is not completely in
sync with the application workload distribution on the server nodes, some nodes may
need to access data stored in
other nodes. In this case, database performance will suffer. Shared nothing architecture
also doesn’t work well with
a large set of database applications such as OLTP (Online transaction processing), which
need to access the entire
database; this architecture will require frequent data redistribution across the nodes and
will not work well. Shared
nothing also doesn’t provide high availability. Since each partition is dedicated to a piece
of the data and workload
which is not duplicated by any other server, each server can be a single point of failure. In
case of the failure of any
server, the data and workload cannot be failed over to other servers in the
cluster.CHAPTER 1 ■ OVERVIEW OF ORACLE RAC
5
In the shared everything architecture, each server in the cluster is connected to a shared
storage where the database
files are stored. It can be either active-passive or active-active. In the active-passive
cluster architecture, at any given
time, only one server is actively accessing the database files and handling workloads; the
second one is passive and in
standby. In the case of active server failure, the second server picks up the access to the
database files and becomes the
active server, and user connections to the database also get failed over to the second
server. This active-passive cluster
provides only availability, not scalability, as at any given time only one server is handling
the workloads.
Examples of this type of cluster database include Microsoft SQL Server Cluster, Oracle Fail
Safe, and Oracle
RAC One Node. Oracle RAC One Node, introduced in Oracle Database 11.2, allows the
single-instance database to
be able to fail over to the other node in case of node failure. Since Oracle RAC One Node
is based on the same Grid
Infrastructure as Oracle RAC Database, it can be converted from one node to the active-
active Oracle RAC Database
with a couple of srvctl commands. Chapter 14 will discuss the details of Oracle RAC One
Node.
In the active-active cluster architecture, all the servers in the cluster can actively access
the database files and
handle workloads simultaneously. All database workloads are evenly distributed to all the
servers. In case of one or
more server failures, the database connections and workloads on the failed servers get
failed over to the rest of the
surviving servers. This active-active architecture implements database server virtualization
by providing users with
a virtual database service. How many actual physical database servers are behind the
virtual database service, and
how the workloads get distributed to these physical servers, is transparent to users. To
make this architecture scalable,
adding or removing physical servers from the cluster is also transparent to users. Oracle
RAC is the classic example of
the active-active shared everything database architecture.

RAC Architecture
Oracle Real Application Cluster (RAC) is an Oracle Database option, based on a share
everything architecture. Oracle
RAC clusters multiple servers that then operate as a single system. In this cluster, each
server actively accesses the
shared database and forms an active-active cluster configuration. Oracle first introduced
this active-active cluster
database solution, called Oracle Parallel Server (OPS), in Oracle 6.2 on VAX/VMS. This
name was used until 2001,
when Oracle released Oracle Real Application Clusters (RAC) in Oracle Database 9i. Oracle
RAC supersedes OPS with
many significant enhancements including Oracle Clusterware and cache fusion technology.
In the Oracle RAC configuration, the database files are stored in shared storage, which
every server in the cluster
shares access to. As shown in Figure 1-1, the database runs across these servers by having
one RAC database instance
on a server. A database instance consists of a collection of Oracle-related memory plus a
set of database background
processes that run on the server. Unlike a single-node database, which is limited to one
database instance per database,
a RAC database has one or more database instances per database and is also built to add
additional database instances
easily. You can start with a single node or a small number of nodes as an initial
configuration and scale out to more
nodes with no interruption to the application. All instances of a database share
concurrent access to the database files.
User connections
RAC
Instance1
RAC
Database
RAC
Instance2
RAC
Instance3

Cluster
Interconnect
Node1
Node2 Node3

Figure 1-1. Oracle RAC Database architectureCHAPTER 1 ■ OVERVIEW OF ORACLE RAC

Oracle RAC is designed to provide scalability by allowing all the RAC instances to share
database workloads.
In this way, Oracle RAC Database presents users with a logical database server that
groups computing resources
such as CPUs and memory from multiple RAC nodes. Most times, with proper
configuration using RAC features
such as services, Single Client Access Name (SCAN), and database client failover features,
changes on the cluster
configuration such as adding or removing nodes can be done as transparently to the users
as possible. Figure 1-1
illustrates an Oracle RAC configuration where users are connected to the database and
can perform database
operations through three database instances.
This architecture also provides HA during a failure in the cluster. It can tolerate N-1 node
failures, where N is
the total number of the nodes. In case of one or more nodes failing, the users connecting
to the failed nodes are
failed over automatically to the surviving RAC nodes. For example, as shown in Figure 1-
1, if node 2 fails, the user
connections on instance 2 fail over to instance 1 and instance 3. When user connections
fail over to the surviving
nodes, RAC ensures load balancing among the nodes of the cluster.
Oracle RAC 12cR1 introduced a new architecture option called Flex Clusters. In this new
option, there are two
types of cluster nodes: Hub nodes and Leaf nodes. The Hub Nodes are same as the
traditional cluster nodes in Oracle
RAC 11gR2. All of the Hub Nodes are interconnected with the high-speed interconnect
network and have direct access
to shared storage. The Leaf Nodes are a new type of node with a lighter-weight stack.
They are connected only with the
corresponding attached Hub Nodes and they are not connected with each other. These
Leaf Nodes are not required
to have direct access to shared storage. Instead, they will perform storage I/O through the
Hub Nodes that they
attach to. The Flex Cluster architecture was introduced to improve RAC scalability.
Chapter 4 will discuss the detailed
configuration of this new feature in 12c.