1. How Cache Fusion Transmits Blocks Across Nodes
Oracle RAC Cache Fusion enables multiple database instances to share a single physical database. When Node 1 requests a row modified by Node 2, the Global Cache Service (GCS) and LMS background processes transfer the dirty buffer directly across the high-speed private interconnect instead of writing to disk.
2. Diagnosing Crucial Global Cache (gc) Wait Events
When Cache Fusion suffers from network latency or high hot-block contention, foreground sessions stall on distinctive wait events:
- gc buffer busy acquire / release: Multiple sessions on the same node or across nodes are requesting exclusive access to the identical data block (e.g., right-hand index inserts or hot sequence buffers).
- gc cr multi block request: Full table scans streaming through the interconnect instead of running local Smart Scans.
- gc current block 2-way / 3-way: Time spent negotiating master block locks across the cluster network.
3. Private Interconnect Optimization: MTU 9000 & UDP Buffers
A standard 1500-byte MTU forces an 8KB Oracle block to be fragmented across 6 Ethernet frames, multiplying interrupt overhead. Setting MTU 9000 (Jumbo Frames) across all cluster switches and NICs ensures each block fits inside a single frame.
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 262144
net.core.wmem_default = 262144
4. Eliminating Interconnect Pinging with Service-Based Routing
The ultimate cure for RAC contention is workload partitioning. Rather than connecting all application threads to a generic default service, create designated services via DBMS_SERVICE:
EXEC DBMS_SERVICE.START_SERVICE('SRV_OLTP');
# Route OLTP exclusively to Node 1, Batch Reporting to Node 2