Limits of Cache Fusion in Reducing Buffer Cache Contention for Large Tables in Oracle RAC 19c

The Short Answer

Cache Fusion does not reliably lower query latency for concurrent read-only workloads on large tables (>10 GB) in Oracle RAC 19c. For large-table scans, Oracle typically employs Direct Path Reads, which bypass the buffer cache entirely. Because Cache Fusion only operates on blocks residing in the buffer cache, it is largely irrelevant to the primary I/O path of OLAP-style scans, explaining the variability in empirical results.

Analysis of Cache Fusion Limits

The Direct Path Read Conflict

In a read-heavy OLAP pattern, the database optimizer frequently chooses full table scans. When the volume of data significantly exceeds the available buffer cache, Oracle uses direct path reads to move data from disk directly into the session's private memory (PGA). Since these blocks never enter the global buffer cache, they cannot be shipped via Cache Fusion to another node. Consequently, increasing concurrency does not trigger a "benefit threshold" for Cache Fusion; instead, it increases contention for disk I/O and interconnect bandwidth.

Impact of Block Size and Parameters

• Block Size: Increasing the block size (e.g., to 16 KB) reduces the total number of global cache messages required to move a specific volume of data. However, for large scans, this primarily optimizes storage I/O efficiency rather than improving Cache Fusion performance.
• Tuning Parameters: There are no supported initialization parameters that guarantee latency improvements for read-only workloads via Cache Fusion. Parameters like cluster_database_instances are configuration settings, not performance knobs. Undocumented parameters (e.g., _fusion_io_size) should be avoided in production as they can lead to instability and are not supported by Oracle.

Verification and Diagnostics

To determine if Cache Fusion is actually impacting your workload, perform the following checks:

1. Verify Access Path: Run DBMS_XPLAN.DISPLAY_CURSOR. If the plan shows TABLE ACCESS FULL and the actual execution involves direct path read wait events, Cache Fusion is not being utilized for that operation.
2. Quantify GC Traffic: Query GV$SYSSTAT for gc cr block received. If this value remains low while latency is high, the bottleneck is I/O or CPU, not the interconnect.
3. Analyze Wait Events: Check AWR reports for gc cr block receive time. If this is high, the interconnect is a bottleneck; if it is low or absent, Cache Fusion is not the primary driver of latency.

Missing Diagnostic Detail: To provide a more tailored recommendation, please provide the Wait Events top-5 list from your AWR report during the peak concurrent load. This will confirm if the bottleneck is direct path read (disk) or gc (interconnect) related.