Introduction
In this article, I will explain Cache Fusion in Oracle RAC.
Cache Fusion is a mechanism that ensures consistency in data processing across instances and accelerates various DML operations on multiple instances.
However, because it involves complex inter-node communication, it can sometimes lead to performance degradation or unexpected issues. Therefore, it is important to have a solid understanding of how Cache Fusion works in order to design systems appropriately and respond effectively to potential problems.
For an overview of the basic concepts of Oracle RAC, please refer to the following article as well.
Oracle RAC Tutorial: Clusterware and ASM Fundamentals for Beginners
What is Oracle RAC? A Complete Guide to Cluster Configuration with Clusterware and ASM
Mechanism for Maintaining Data Consistency
In an Oracle RAC environment, the Global Resource Directory (GRD) keeps track of the latest information about data blocks to maintain consistency across various DML operations.
Based on this information, the Global Enqueue Service (GES) and Global Cache Service (GCS) manage data locks and cache, ensuring data consistency across multiple instances.
The following section explains key terms used in this context.
| Terms | Definitions |
|---|---|
| GRD (Global Resource Directory) | An internal database that keeps track of the state of data blocks. Since storing this data consumes memory, it is recommended to allocate approximately 10% more SGA when using Oracle RAC. |
| GES (Global Enqueue Service) | A service that coordinates enqueue operations shared both locally and globally. It also handles deadlock detection and request timeout management. |
| GCS (Global Cache Service) | A primary global resource that coordinates access to data blocks in the buffer caches of multiple Oracle RAC instances, ensuring cache consistency. – It acts as the control process that implements Cache Fusion, tracks the latest data block information, and manages block transfers between instances. – It is implemented via various background processes such as LMSn (Global Cache Service Processes) and LMD (Global Enqueue Service Daemon). |
| LMON (Global Enqueue Service Monitor) | Monitors the entire cluster and manages global resources. It is also responsible for handling abnormal termination of instances or processes and managing recovery related to GES and GCS. |
| LMD (Global Enqueue Service Daemon) | A resource agent process that manages resource requests for the Global Enqueue Service. It also handles deadlock detection and GES requests. |
| LCK0 (Instance Enqueue Process) | Manages requests for resources other than data blocks, such as library cache requests. |
| LMSn (Global Cache Service Process) | A key process that controls resources across instances and implements Cache Fusion. It handles sending, receiving, and processing GCS-related messages, including GCS requests and block transfers. |
How Cache Fusion Works
In this section, we explain the mechanism of Cache Fusion implemented by the Global Cache Service (GCS).
As an example, I will illustrate the flow in which a data block updated on one instance is accessed from another instance.
Since the behavior differs depending on whether the update has been committed, I will explain each case separately.
Case: Update on a Single Node Has Been Committed
- Update the data block on Instance A
Execute an UPDATE statement on Instance A to modify the target data block (Current Block). - Commit the update
Committing the statement confirms the block as being in the Current state. - Perform a read request on Instance B
Execute a SELECT statement on Instance B to access the data updated in step 1. - GCS queries the resource master
GCS checks with the resource master to identify the holder of the requested block.
– Holder: the instance that currently holds the latest block
– Resource Master: the instance that knows which instance holds the latest block
In this example, Instance A acts as both the resource master and the holder, but in other cases, they can be different instances. - Block transfer instruction
Since Instance A is the holder, GCS instructs it to transfer the block to Instance B. - Transfer the Current Block
The latest Current Block is transferred from Instance A to Instance B. - Transfer completion notification
Instance A notifies Instance B that the block transfer has been completed. - Complete the read on Instance B
Instance B receives the transferred Current Block and can now read the latest data.
Case: Update on a Single Node Has Not Been Committed
- Update the data block on Instance A (before commit)
Execute an Update statement on Instance A to modify the target data block in its buffer cache, marking it as the Current Block. - Perform a read request on Instance B
Execute a Select statement on Instance B to read the data updated in step 1. - GCS queries the resource master
GCS checks with the resource master to identify the holder of the requested block. - Block transfer instruction
GCS instructs the holder, Instance A, to transfer a CR block (Consistent Read Block). - CR block generation
Instance A uses UNDO information to create a CR block, ensuring read consistency for Instance B. - Transfer the CR block
The CR block is transferred from Instance A to Instance B. - Transfer completion notification
Instance B acknowledges receipt of the CR block to Instance A via GCS. - Read completion on Instance B
Instance B uses the transferred CR block to access the data while maintaining read consistency.
Summary
In this article, we explained Cache Fusion in Oracle RAC and the flow of data block transfers.
Cache Fusion is a mechanism that enables high-speed DML operations while maintaining data consistency across multiple instances. The Global Resource Directory (GRD) manages the state of data blocks, while the Global Enqueue Service (GES) and Global Cache Service (GCS) control locks and block transfers, ensuring consistent distributed processing.
An important point to note is that the block transfer behavior differs depending on whether the update has been committed. If committed, the Current Block is transferred; if not, a Consistent Read (CR) block is generated using UNDO information.
Understanding this mechanism allows for more effective Oracle RAC design, performance tuning, and troubleshooting.
English 
Japanese
コメント