How does RAC ensure cache consistency?
In an Oracle RAC environment, multiple servers (instances) are all reading and writing to the same physical database at the same time. This creates a massive challenge: how do you prevent Node A from overwriting a change that Node B just made in its local memory?
In a single-instance database, this is easy because there is only one memory area (the SGA). In RAC, Oracle uses a sophisticated technology called Cache Fusion to ensure that every node always has the most up-to-date version of a data block without constantly hitting the slow disk.
Before RAC existed, nodes had to write data to disk so another node could read it (a process called "Ping"). It was painfully slow.
Cache Fusion allows nodes to transfer data blocks directly from one server’s RAM to another’s RAM over a high-speed Private Interconnect. It treats the combined memory of all servers in the cluster as one giant, "fused" global cache.
To keep track of who has what, Oracle maintains the GRD. Think of the GRD as a massive, real-time map that knows:
Which node has a copy of a specific data block.
What mode that block is in (Is it being read? Is it being modified?).
Which node has the most recent "dirty" (modified) version of the data.
The GRD isn't stored in one place; it’s distributed across all nodes in the cluster to prevent a single point of failure.
To manage consistency, every block in a node's cache is assigned a state:
Null (N): The node doesn't have the block.
Shared (S): The node has the block for reading. Other nodes can have it for reading too.
Exclusive (X): The node is modifying the block. No other node can have it in Shared or Exclusive mode.
Imagine Node A wants to update a row in "Block 500," but Node B currently has that block in its memory.
The Request: Node A asks the GRD, "Who owns Block 500? I need to update it."
The Directive: The GRD sees that Node B has it. It tells Node B, "Send a copy of Block 500 to Node A."
The Transfer: Node B sends the block directly to Node A over the high-speed Interconnect.
The Handover: Node B marks its copy as invalid (or "Null"). Node A receives the block, marks it as Exclusive, and performs the update.
The Update: The GRD is updated to show that Node A is now the "Master" of the latest version of Block 500.
Crucially, the data never touched the disk during this exchange.
What if the power fails before Node A writes that change to disk? RAC ensures that even if a block is "dirty" (modified but not yet saved to disk), the cluster knows which node has the "Latest Revision." If Node C suddenly needs that same block, Node A will ship the dirty image directly to Node C. This ensures Read Consistency across the entire cluster.
Since Cache Fusion relies entirely on the private network between servers, the Interconnect is the heartbeat of a RAC system.
If the network is slow, Cache Fusion slows down.
If the network is congested, you will see wait events like gc cr block receive or gc current block busy.
Cache Fusion is what makes RAC "transparent." You don't have to write your application specifically for a cluster; Oracle handles the data movement behind the scenes. It ensures that no matter which server a user connects to, they are always seeing the "Truth."
Peer Tip: If you see high "Global Cache" (gc) wait events in your AWR report, it’s a sign that your nodes are "fighting" over the same data. This is called Data Contention. Sometimes, the best way to fix a RAC performance issue isn't a faster network—it's tuning the SQL to stop multiple nodes from needing the same blocks at the same time.