4.2 RAC architecture

---

In Chapter 2 (Hardware Concepts) the clustering options available via the various technologies (SMP, MPP, NUMA, etc.) were discussed extensively. All of these hardware architectures support applications that take advantage of these clustered solutions. One such database application is RAC.

RAC is a clustered database solution that requires a two or more node hardware configuration capable of working together under a clustered operating system. A clustered hardware solution is managed by cluster management software, usually provided by the hardware vendor. The operating system is also responsible for providing access to the shared disk subsystems.

RAC supports all standard Oracle 9i features such as fast commits, group commits and deferred writes. It supports the standard row level locking across instances. Under this new technology, blocks can be shared by multiple transactions, accessing the data from any of the instances participating in the clustered configuration.

Apart from the support for the standard features of a single instance of Oracle, RAC provides additional performance from multiple instances by enabling the following features:

• Cache fusion: Cache fusion is a cache coherency mechanism to transfer requests for specific blocks via the cluster interconnect, thus improving performance.

• Sequence generators: RAC provides a clustered database solution with the database shared between two or more instances. All objects, including sequence numbers in the shared database, are accessible from one or more instances simultaneously.

• System change number (SCN): The system change number generated on one instance is communicated via the cluster interconnect to the other instances providing a single view of the transaction status across all instances. This communication of SCN across the interconnect takes place without any additional overhead, by piggy backing against any message that is passed across the cluster interconnect. An SCN is at least 48 bits long. Thus they can be allocated at a rate of 16,384 SCNs per second for over 534 years without running out of them.

• Failover: A clustered configuration consists of two or more nodes participating as a collective configuration. In a clustered database, this type of configuration provides application failover by allowing reconnection to the database using another active instance in case the connection to the original instance is broken.

• Scalability: By allowing members in a cluster to leave (in case of node failures, or for maintenance) or join the cluster (in case new nodes are added to the cluster), RAC provides scalability. Scalability helps to add additional configurations based on increased user requirements.

Figure 4.1 illustrates the various components of the clustered hardware configuration. It is composed of:

• Cluster manager (CM)

• Shared disk driver (disk group manager)

• Communication layer

• Interprocess communication protocol (IPC)

• Listeners

• Monitors

Figure 4.1: Real Application Cluster architec ture.

Cluster manager (CM) is part of the clustered operating system that is responsible for providing cluster integrity. A high-speed interconnect is used to provide communication between nodes in the cluster. The CM uses the interconnect to process heartbeat messages between nodes. The function of the heartbeat messaging system is to determine which nodes are logical members of the cluster and to update the membership information on the nodes. Basically, the heartbeat messaging system enables the CM to understand how many members are in the cluster at any given point of time.

The communication layer manages the communication between the nodes. Its responsibility is to configure and pass messages across interconnect, to the other nodes in the cluster. While the CM uses the messages returned by the heartbeat mechanism, it is the responsibility of the communication layer to ensure the transmission of the message to the CM.

Interprocess communication protocol (IPC) in a clustered configuration is responsible for packaging the Oracle messages and passing them to and from the communication layer for the interconnect access.

Various monitor processes consistently verify different areas of the system. The heartbeat monitor continually verifies the functioning of the heartbeat mechanism.

The listener monitor verifies the listener process and the instance monitor verifies the functioning of the instance.

The majority of the messages passed via the interconnect are related to GCS which comprises the global enqueues, data blocks, and lock granula rity information. GCS uses the cache fusion architecture to communicate between the various caches (cache to cache) of the members in the cluster.

---