RAC

Cache Fusion is the technology that allows Oracle RAC nodes to share a single consistent view of the database buffer cache across all instances. Without it, every cross-instance read or write would require a disk I/O. With it, dirty blocks travel directly from one instance’s buffer cache to another across the private interconnect. Understanding how this works is the foundation for diagnosing RAC-specific performance problems. The Problem Cache Fusion Solves In a traditional single-instance Oracle database, the buffer cache is authoritative. When an instance needs a block, it either finds it in cache or reads it from disk. In RAC, multiple instances have their own buffer caches, but they share the same datafiles. Without coordination, Instance A and Instance B could each have different versions of the same block in cache — a consistency nightmare. ...

The private interconnect is the central nervous system of an Oracle RAC cluster. Poor interconnect performance cascades directly into gc cr block 2-way, gc current block 2-way, and related wait times. Before tuning any Oracle parameter, the interconnect hardware and OS configuration must be validated. This article covers the full stack — from NIC configuration to Oracle’s use of the network. Interconnect Architecture Options Technology Bandwidth Latency Use Case 1 GbE 1 Gb/s ~100–200μs Small, low-traffic clusters only 10 GbE 10 Gb/s ~20–50μs Standard current minimum 25 GbE 25 Gb/s ~10–20μs High-throughput OLAP/mixed RoCE (RDMA over Ethernet) 25–100 Gb/s ~1–5μs Modern Exadata, high-performance InfiniBand (EDR) 100 Gb/s <1μs Pre-X8M Exadata, HPC For new deployments, 25 GbE minimum is the practical recommendation. On Exadata X8M+, RoCE is the default interconnect technology, delivering near-InfiniBand latency over standard Ethernet infrastructure. ...

Oracle RAC Services are the primary mechanism for workload management in a RAC cluster. Rather than connecting directly to an instance (which bypasses all intelligent routing), applications connect to a named service, and Oracle manages where that service is active. Combined with Application Continuity (AC), services provide seamless failover that is invisible to most application workloads. Services Fundamentals A service is a named workload bucket with the following attributes: Preferred instances: Primary instances where the service is active. Available instances: Failover instances where the service moves if a preferred instance fails. Cardinality: SINGLETON (active on one instance at a time) or UNIFORM (active on all instances simultaneously). Role: PRIMARY or PHYSICAL_STANDBY (for Active Data Guard integration). # List all services in the cluster srvctl status service -d ORCL # Add a service for OLTP (preferred on instance 1, failover to instance 2) srvctl add service \ -d ORCL \ -s OLTP_SVC \ -preferred ORCL1 \ -available ORCL2 \ -cardinality SINGLETON \ -pdb PDB1 # Add a uniform service for read workloads (active on all instances) srvctl add service \ -d ORCL \ -s REPORT_SVC \ -preferred "ORCL1,ORCL2" \ -cardinality UNIFORM \ -pdb PDB1 srvctl start service -d ORCL -s OLTP_SVC srvctl start service -d ORCL -s REPORT_SVC Service-Level Performance Attributes Services can be annotated with performance and connection management attributes that affect how the Oracle Net listener and connection pool handle connections: ...