Introduction to Oracle Real Application Clusters

Introduction to Oracle Real Application Clusters

Unlike a normal Oracle database, where there’s a single instance for the entire database, Oracle Real Application Clusters allows multiple instances to access a single database, and an Oracle RAC database can have a maximum of 100 instances. Instances running on multiple server nodes access the common set of datafiles comprising a single database. In a single-instance environment, one Oracle database is used by only one instance running on a server machine; thus, users accessing the database can connect to the database via that single server only. The processing resources (CPU memory and so on) available for the database work are limited to the single server’s processing resources.

A cluster is a set of connected servers that appear as one entity to the end users and applications. Oracle RAC relies on Oracle Clusterware for making this possible. Oracle Clusterware connects the servers behind the scenes so that they work together as one logical entity. Oracle Clusterware provides the backbone, or the infrastructure, that makes Oracle RAC possible.

In an Oracle RAC environment, because multiple instances use the same database, database users gain from a higher throughput and the stability offered by a cluster - if one of the instances goes down, the database continues to remain accessible through the remaining running instances. As far as the users are concerned, the cluster, which consists of a set of servers hosting each of the instances, appears as a single entity. In an Oracle RAC database, there’s an additional thread of redo for each instance in the cluster, as well as a dedicated undo tablespace for each of the instances.


An instance is a set of background processes and memory structures operating in a machine associated with the database. A database is a collection of physical files. A database and an instance have a one-to-many relationship. A database can be concurrently mounted by more than one instance in Oracle RAC, and at any point, one instance will be part of only one database.

The nonvolatile storage for datafiles comprising the database is equally available to all the nodes for read and write access. Oracle RAC needs to coordinate and regulate simultaneous data accesses from multiple server nodes. Hence, an efficient, reliable, and high-speed private network must exist among the nodes of the cluster for sending and receiving data. Figure 1 shows the configuration of a single-instance database and an Oracle RAC database.

 Single-instance database and an Oracle RAC setup

FIGURE 3-1. Single-instance database and an Oracle RAC setup

Single-Instance Environment vs. Oracle RAC Environment

Similar to in a single-instance environment, each instance in an Oracle RAC environment has its own System Global Area (SGA) and background processes. However, all the datafiles and control files are equally accessible to all the nodes, so these files must be placed on a shared disk subsystem. Each instance also has its own dedicated set of online redo log files. The online redo log files can be written to only by the instance to which they belong. However, these files must be readable by other instances during instance crash recovery. This requires that online redo log files reside on a shared disk subsystem and not on a node’s local storage, because the files would be lost if the node crashed.


An Oracle RAC database can have up to 100 instances.

Table 1 compares single-instance components to components of an instance in an Oracle RAC environment.


TABLE 1. Components of a Single-Instance Environment vs. an Oracle RAC Environment

Instances in an Oracle RAC environment share the data because the same set of data might be needed by multiple instances simultaneously. There is no danger in multiple instances reading the same data simultaneously; however, data integrity issues may arise if one instance modifies (via insert or update) data while one or more other instances read or multiple instances modify the same data concurrently. This concurrent read/write or write/write behavior, if not coordinated correctly, might lead to data corruption or inconsistent representation of the data. Single-instance Oracle already ensures that readers never block writers and that “dirty” reads are never allowed.

Oracle RAC ensures that all the instances across the clusters see a consistent image of the database. The Distributed Lock Manager (DLM), also called the Global Resource Directory (GRD), coordinates resource sharing among the instances.

Oracle Flex Clusters

When you’re running an Oracle RAC with a large number of nodes, an Oracle Flex Cluster is a good solution. All nodes in such a cluster belong to a single Oracle Grid Infrastructure cluster.

You can use the Oracle Flex Clusters architecture to centralize policy decisions when deploying resources for various applications, as well as to manage responses to service-level failures and to manage recovery.

An Oracle Flex Cluster consists of two types of nodes:

   Hub nodes   The hub nodes are tightly connected to other nodes and have direct access to shared storage. Hub nodes are similar to Oracle RAC Databases in previous releases of Oracle.

   Leaf nodes   Leaf nodes are loosely coupled with hub nodes and may not have direct access to shared storage.


You can convert a hub node to a leaf node, and vice versa, without any downtime.

You can have up to 64 hub nodes in an Oracle Flex Cluster, and you can have a large number of leaf nodes. You can use the two types of nodes to run different types of applications.

The Oracle RAC database instances you run on the leaf nodes in an Oracle Flex Cluster are called reader nodes. You can run a large number of reader nodes (up to 64 nodes) on a hub node in order to run massive parallel queries for crunching through large datasets. Oracle recommends that you allocate as much memory as possible to the reader nodes for parallel queries to use.

Once you set up the reader nodes and the read-only database instances, you can create services that point queries to these nodes for better parallel query performance. The database instances that run on reader nodes are quite different from instances running on the hub node. Note the following about these instances:

   The database instances run in a read-only mode.

   As long as the hub node to which a set of reader nodes is connected is still part of a cluster (that is, not evicted), the reader nodes can continue running without any performance slowdown.

Oracle Extended Clusters

Normally, you run the Oracle RAC environment from a single datacenter. However, you can configure Oracle RAC on an Oracle extended cluster, where the nodes of the cluster are geographically dispersed between multiple datacenters in the same area or even in different cities.

An extended-distance (or simply, extended) cluster is a special Oracle RAC architecture that allows you to provide fast recovery from a site failure by letting all nodes in all the sites process transactions as part of a single database cluster. For disaster recovery, Oracle recommends that you run Oracle Data Guard along with Oracle RAC. You must consider whether an extended cluster is suitable for you due to the additional latency from the cluster being spread out across a large area.

Although an extended cluster provides higher availability than a local Oracle RAC setup, it cannot protect you against all types of outages. For comprehensive data protection, Oracle recommends that you use Oracle Data Guard along with Oracle RAC.

Oracle Multitenant and Oracle RAC

The Oracle Multitenant option of Oracle Database 12c helps you consolidate databases and simplify provisioning and upgrades. Oracle Multitenant enables you to create a container database (CDB) that holds multiple pluggable databases (PDBs).

You can convert your normal Oracle databases into PDBs. You can create an Oracle RAC database as a CDB and then plug all your PDBs into the CDB. In an Oracle RAC environment, the multitenant CDB is based on Oracle RAC, with multiple instances of Oracle RAC CDB running. You can choose to make each of the PDBs available on some or all of the instances of the Oracle RAC CDB.

Because a PDB isn’t automatically started in a CDB instance, you must manually start the PDB on an Oracle RAC CDB, The PDB services will also be made available when you assign the first dynamic database services to a PDB. The PDB will then be available on the instances on which your service runs.

 Now let's look at Administrator-Managed and Policy-Managed Databases comparison and Oracle RAC Components.

Вас заинтересует / Intresting for you:

Recovering from Undo Tablespac...
Recovering from Undo Tablespac... 941 views Aida Thu, 26 Jul 2018, 08:00:38
Basic Oracle Database 12c Secu...
Basic Oracle Database 12c Secu... 1842 views Zero Cool Sat, 06 Oct 2018, 13:53:13
Oracle Database Kernel Compone...
Oracle Database Kernel Compone... 420 views Боба Sun, 05 Jul 2020, 08:37:08
Oracle RAC Solution short revi...
Oracle RAC Solution short revi... 220 views Боба Sun, 21 Jun 2020, 12:06:33