Oracle RAC Cache Fusion: How Oracle Shares Data Between RAC Nodes

Cache Fusion is the technology that makes Oracle RAC unique.

In a traditional single-instance database, all users access the same buffer cache. In Oracle RAC, each instance has its own SGA and Buffer Cache, yet all instances access the same database.

So, what happens when Instance 2 needs a block that is already cached in Instance 1?

Does Oracle write the block to disk first?

The answer is No.

Instead, Oracle transfers the block directly from one instance’s memory to another through the private interconnect. This process is called Cache Fusion, and it is one of the key innovations that enables Oracle RAC to deliver both scalability and high availability.

In this article, we’ll explore how Cache Fusion works, the roles of GCS and GES, how to monitor block transfers, and how to troubleshoot performance issues.

What is Cache Fusion?

Cache Fusion allows Oracle RAC instances to exchange database blocks directly through memory.

Instead of reading a block from disk, one instance can request it from another instance that already has the most recent copy.

Example:

              Shared Database Files
                     ▲
                     │
         +-----------+-----------+
         |                       |
   +-------------+         +-------------+
   |  Instance 1 |         |  Instance 2 |
   | Buffer Cache|<------->| Buffer Cache|
   +-------------+         +-------------+
            Private Interconnect

This avoids unnecessary disk I/O and significantly improves response times.

Why Cache Fusion Matters

Without Cache Fusion, the process would be:

1. Instance 1 writes the modified block to disk.
2. Instance 2 reads the block from disk.

With Cache Fusion:

1. Instance 2 requests the block.
2. Instance 1 sends the block directly through the private interconnect.

Result:

• Less disk I/O
• Lower latency
• Better scalability

Example

Suppose:

User A updates a customer record on Instance 1.

A few milliseconds later:

User B queries the same customer on Instance 2.

Instead of reading from disk:

Instance 2
      │
Request Block
      │
Private Interconnect
      │
Instance 1
      │
Send Current Block

The latest version of the block arrives directly from Instance 1.

Cache Fusion Components

Cache Fusion relies mainly on two services.

Global Cache Service (GCS)

The Global Cache Service manages database blocks.

Responsibilities include:

• Block ownership
• Buffer cache coordination
• Block transfer
• Cache consistency

Think of GCS as the manager of all cached blocks across the cluster.

Global Enqueue Service (GES)

The Global Enqueue Service manages locks and shared resources.

Responsibilities include:

• Global locks
• Resource synchronization
• Deadlock detection
• Distributed resource management

While GCS manages blocks, GES manages locks.

Cache Fusion Workflow

A simplified sequence:

Instance 2
     │
Requests Block
     │
GCS checks owner
     │
Instance 1 owns block
     │
Block transferred
     │
Instance 2 continues

All of this typically happens in milliseconds.

Block States

A database block can exist in different states.

State	Description
Current	Latest version of the block
Consistent Read (CR)	Read-only version used for queries
Dirty	Modified but not yet written to disk

Oracle transfers either the current block or a consistent-read copy, depending on the request.

Current Block Transfer

Example:

Instance 1

Current Block

        │

Private Interconnect

        │

Instance 2

Used when another instance needs the latest version of the block.

Consistent Read (CR) Block

When a query only needs a read-consistent version:

Instance 1

CR Block

      │

Transfer

      │

Instance 2

No physical disk read is required.

Monitoring Cache Fusion

Oracle provides several dynamic performance views.

Global Cache statistics:

SELECT name,
       value
FROM gv$sysstat
WHERE name LIKE 'gc%';

Useful statistics include:

• gc current blocks received
• gc cr blocks received
• gc current blocks served
• gc cr blocks served

These counters show how frequently instances exchange blocks.

Monitoring Wait Events

Cache Fusion waits appear in GV$SYSTEM_EVENT.

Example:

SELECT event,
       total_waits,
       time_waited
FROM gv$system_event
WHERE event LIKE 'gc%';

Common events include:

• gc cr request
• gc current request
• gc buffer busy
• gc current block busy

Some waits are expected in RAC. Focus on unusual increases or sustained high wait times.

Identify Interconnect Activity

Monitor interconnect traffic:

SELECT inst_id,
       bytes_sent,
       bytes_received
FROM gv$ges_statistics;

A sudden increase in traffic may indicate excessive block transfers between instances.

Check Global Cache Performance

Oracle also provides useful RAC statistics:

SELECT inst_id,
       statistic_name,
       value
FROM gv$osstat
WHERE statistic_name LIKE '%INTERCONNECT%';

These metrics can help identify network bottlenecks affecting Cache Fusion.

Block Pinging

A block that constantly moves between instances is said to be pinging.

Example:

Instance 1

      │

Block

      │

Instance 2

      │

Back Again

      │

Instance 1

Frequent block movement increases interconnect traffic and reduces performance.

Common causes include:

• Hot tables
• Hot indexes
• Poor application design

Common Cache Fusion Wait Events

Wait Event	Meaning
gc cr request	Waiting for a consistent-read block
gc current request	Waiting for the current block
gc current block busy	Current block is temporarily unavailable
gc buffer busy	Buffer contention across instances

These waits should always be interpreted in the context of workload and application behavior.

Common Performance Issues

Slow Private Interconnect

Symptoms:

• High gc waits
• Slow SQL execution
• Longer block transfer times

Verify network latency:

ping <private_ip>

Also review switch configuration, MTU settings, and packet loss.

Hot Blocks

Symptoms:

• Frequent block transfers
• High interconnect utilization

Possible causes:

• Sequential inserts
• Small lookup tables updated frequently
• Index contention

Consider redesigning the application or partitioning the workload.

Slow Storage

Although Cache Fusion reduces disk reads, database writes still depend on storage performance.

Monitor:

• ASM performance
• I/O latency
• Storage queues

Excessive Cross-Instance Traffic

If sessions constantly access data owned by another instance, Cache Fusion traffic increases.

A better service placement strategy may reduce unnecessary block transfers.

Useful RAC Performance Views

Global sessions:

SELECT inst_id,
       username,
       machine
FROM gv$session;

Active transactions:

SELECT inst_id,
       xidusn,
       xidslot
FROM gv$transaction;

Global locks:

SELECT inst_id,
       resource_name,
       state
FROM gv$ges_resource;

These views help correlate application activity with Cache Fusion behavior.

Best Practices

• Use a low-latency private interconnect (10 GbE or faster for most production environments).
• Separate public and private network traffic.
• Design services to minimize unnecessary cross-instance access.
• Monitor gc wait events regularly.
• Investigate hot blocks before increasing hardware resources.
• Keep Grid Infrastructure and database software up to date.

Production Scenario

A customer reported that a critical OLTP application became slower after adding a second RAC node.

The database showed no storage issues, and CPU utilization was low.

However, AWR reports revealed a significant increase in:

• gc current request
• gc current block busy

The investigation showed that all application sessions connected randomly to both RAC instances while updating the same set of rows in a heavily used table.

By relocating the OLTP service so that the workload primarily ran on one preferred instance, cross-instance block transfers dropped significantly, Cache Fusion waits decreased, and response times improved without any hardware changes.

DBA Tip

Many people believe that more RAC nodes always mean better performance.

In reality, adding nodes increases the need for coordination between instances.

If an application constantly updates the same data from multiple instances, Cache Fusion traffic increases and performance may actually decline.

A well-designed RAC application minimizes unnecessary block movement by placing related workloads on the same instance whenever practical.

Cache Fusion is extremely fast, but avoiding unnecessary block transfers is even faster. The best RAC performance often comes from smart workload placement rather than simply adding more nodes.

Conclusion

Cache Fusion is the technology that allows Oracle RAC instances to operate as a single database while maintaining separate memory structures. By transferring blocks directly through the private interconnect, Oracle reduces disk I/O and provides fast, consistent access to shared data.

Understanding how GCS, GES, block transfers, and Cache Fusion wait events work is essential for diagnosing RAC performance issues and designing scalable applications.