Oracle RAC Cache Fusion Internals – How Data Blocks Move Between RAC Nodes and How to Optimize Performance

Introduction

Oracle Real Application Clusters (RAC) enables multiple database instances to access a single shared database simultaneously, providing high availability, fault tolerance, and horizontal scalability. One of the core technologies behind Oracle RAC is Cache Fusion, which allows database blocks to be transferred directly between RAC instances through the private interconnect instead of performing physical disk reads.

While Cache Fusion significantly improves performance, poorly designed applications or inefficient workloads can generate excessive block transfers, resulting in cluster wait events such as gc current request, gc cr request, and gc buffer busy acquire.

This article explains how Cache Fusion works internally, the role of Oracle RAC services such as GCS and GES, common performance bottlenecks, and practical techniques to optimize Cache Fusion performance.

What is Oracle RAC Cache Fusion?

Cache Fusion is Oracle RAC’s mechanism for sharing data blocks between database instances.

Instead of writing a modified block to disk and having another instance read it back, Oracle transfers the block directly over the RAC private interconnect.

This provides:

• Faster block access
• Reduced physical I/O
• Improved scalability
• Better application response time

Without Cache Fusion, RAC performance would be significantly lower because every shared block request would require disk access.

Oracle RAC Architecture

A typical Oracle RAC environment consists of:

• Multiple Oracle Database Instances
• Shared Storage (ASM)
• High-Speed Private Interconnect
• Global Cache Service (GCS)
• Global Enqueue Service (GES)

                Oracle RAC Cluster

+------------+                     +------------+

|  Instance1 |                     | Instance2  |

|   Node-1   |<----Cache Fusion--->|   Node-2   |

+------------+                     +------------+

        \                              /

         \                            /

          \                          /

        High-Speed Private Interconnect

                   |

              Shared ASM Storage

How Cache Fusion Works

Suppose Instance 2 requires a data block that is currently stored in the buffer cache of Instance 1.

Instead of reading the block from disk:

1. Instance 2 requests the block.
2. Oracle Global Cache Service identifies the owning instance.
3. Instance 1 transfers the block through the private interconnect.
4. Instance 2 receives the block directly into its buffer cache.
5. The SQL operation continues.

This entire process occurs in memory without physical disk access.

Current Block vs Consistent Read (CR) Block

Oracle RAC transfers two different block types.

Current Block

Current blocks contain the most recent version of the data.

Used for:

• INSERT
• UPDATE
• DELETE
• MERGE

Only one instance owns the current block at any point in time.

Consistent Read (CR) Block

CR blocks represent a read-consistent copy of the data.

Used for:

• SELECT statements
• Reporting
• Read-only queries

Multiple RAC instances can simultaneously hold CR copies.

Global Cache Service (GCS)

The Global Cache Service is responsible for managing database blocks across the RAC cluster.

Responsibilities include:

• Tracking which instance owns each block
• Managing Current and CR blocks
• Coordinating block transfers
• Reducing block contention

Without GCS, Cache Fusion cannot function.

Global Enqueue Service (GES)

GES manages global locks and shared resources.

Responsibilities include:

• Coordinating distributed locks
• Preventing data corruption
• Synchronizing resource access
• Managing enqueue contention

RAC Private Interconnect

The Private Interconnect is the communication channel between RAC nodes.

It carries:

• Cache Fusion traffic
• GCS messages
• GES messages
• Cluster heartbeat

Oracle recommends:

• Dedicated private network
• Low latency
• High bandwidth
• 10GbE or faster

A slow interconnect directly impacts Cache Fusion performance.

Common Cache Fusion Wait Events

Wait Event	Meaning
gc current request	Waiting for the latest version of a block
gc cr request	Waiting for a consistent read copy
gc buffer busy acquire	Requested block is currently busy
gc buffer busy release	Waiting for another session to release a block
gc current block busy	Current block is locked by another instance
gc write	Waiting during global cache write operations

Why Cache Fusion Contention Happens

Cache Fusion itself is not the problem.

Contention occurs because multiple instances continuously compete for the same data blocks.

Typical causes include:

• High concurrency on the same rows
• Hot index leaf blocks
• Excessive INSERT operations
• Frequent UPDATE statements
• Full table scans
• Poor partitioning
• Slow private interconnect
• Poor SQL execution plans

How to Reduce Cache Fusion Contention

1. Eliminate Hot Blocks

When thousands of sessions update the same block, Oracle continuously transfers ownership between RAC nodes.

Solutions:

• Redesign application logic
• Distribute workload
• Partition large tables

2. Use Reverse Key Indexes

Sequential primary keys often create right-hand index hot blocks.

Example:

CREATE INDEX idx_orders

ON orders(order_id)

REVERSE;

This distributes inserts across multiple index leaf blocks.

3. Partition Large Tables

Instead of inserting into one partition:

ORDERS

Partition by:

• Date
• Region
• Customer
• Hash

Benefits:

• Reduced contention
• Better scalability
• Improved parallelism

4. Configure RAC-Friendly Sequences

Avoid:

ORDER

Use:

CACHE 1000

NOORDER

Example:

CREATE SEQUENCE order_seq

CACHE 1000

NOORDER;

This minimizes sequence-related block transfers.

5. Keep Transactions Short

Large transactions hold blocks longer.

Recommendations:

• Commit frequently
• Avoid unnecessary updates
• Batch large operations

6. Use RAC Services

Instead of allowing all nodes to process write-intensive transactions:

Assign write services to a preferred instance.

Benefits:

• Reduced block movement
• Better locality
• Lower cluster waits

7. Optimize SQL

Poor SQL causes unnecessary block access.

Always:

• Use proper indexes
• Avoid unnecessary full table scans
• Filter data efficiently
• Review execution plans

8. Monitor AWR and ASH

Review:

• Top Wait Events
• Top SQL
• Top Segments
• Cluster Waits
• Hot Objects
• Hot Blocks

These reports help identify Cache Fusion bottlenecks before they become critical.

Useful Diagnostic Queries

Top Cache Fusion Wait Events

SELECT event,

       COUNT(*)

FROM gv$session

WHERE state='WAITING'

AND event LIKE 'gc%'

GROUP BY event

ORDER BY COUNT(*) DESC;

SQL Causing Cluster Waits

SELECT sql_id,

       COUNT(*)

FROM gv$active_session_history

WHERE event LIKE 'gc%'

GROUP BY sql_id

ORDER BY COUNT(*) DESC;

Identify Hot Blocks

SELECT current_file#,

       current_block#,

       COUNT(*)

FROM gv$active_session_history

GROUP BY current_file#, current_block#

ORDER BY COUNT(*) DESC;

Find Hot Objects

SELECT owner,

       object_name,

       object_type,

       COUNT(*)

FROM gv$active_session_history ash

JOIN dba_objects obj

ON ash.current_obj# = obj.object_id

WHERE ash.event LIKE 'gc%'

GROUP BY owner, object_name, object_type

ORDER BY COUNT(*) DESC;

Best Practices Checklist

• Use Reverse Key Indexes where appropriate.
• Partition high-DML tables.
• Configure NOORDER CACHE sequences.
• Keep transactions short.
• Design applications to avoid hot rows.
• Use RAC Services for workload distribution.
• Monitor AWR, ASH, and GV$ views regularly.
• Ensure a dedicated, low-latency private interconnect.
• Optimize SQL execution plans.
• Review cluster wait events proactively.

Conclusion

Oracle RAC Cache Fusion is one of the key technologies that makes Oracle RAC highly scalable and resilient. It eliminates unnecessary disk I/O by transferring data blocks directly between database instances through the private interconnect.

However, Cache Fusion should not be viewed as a performance problem. Most issues arise from application design, excessive concurrency, inefficient indexing, poor partitioning strategies, or unoptimized SQL. By understanding how Cache Fusion works and applying best practices such as Reverse Key Indexes, partitioning, RAC-aware sequence configuration, workload isolation, and continuous performance monitoring, DBAs can significantly reduce cluster contention and build RAC environments that scale efficiently under heavy workloads.