Oracle RAC Architecture, Shared Database, Multiple Instances, Cache Fusion, and GCS/GES

Learning outcomes

ServiceHub outgrows one database server and the platform team proposes “RAC so every query runs on two servers.” That is the wrong mental model. Oracle Real Application Clusters (RAC) lets multiple database instances—each with its own System Global Area (SGA), background processes and private redo/undo context—open and modify the same shared database files. Oracle coordinates those caches and locks across the cluster. RAC can improve availability and scale some concurrent workloads, but every cross-instance block dependency adds coordination work.

1. RAC is many instances opening one database

A database is the persistent set of control files, datafiles and online redo-log structures. An instance is memory plus processes that operate on those files. In RAC, all participating instances open the same database, so they see the same committed application data and dictionary while keeping separate buffer caches/shared pools and instance-specific process state.

2. Cache Fusion keeps separate buffer caches coherent

Cache Fusion is Oracle RAC's disk-less cache-coherency mechanism. If instance 2 needs a block whose useful version is in instance 1's buffer cache, Oracle can transfer the block image directly over the private interconnect rather than force instance 1 to write it to disk and instance 2 to read it back.

The Global Cache Service (GCS) coordinates cached database blocks. The Global Enqueue Service (GES) coordinates enqueues and other globally managed resources. Together they maintain the distributed Global Resource Directory (GRD), which tracks global ownership/state across active instances.

3. Current blocks and consistent-read blocks have different intents

A session modifying a row needs an appropriate current block version. A reader can need a consistent read (CR) block reconstructed for its query SCN. GCS can ship current or CR copies between instances while preserving global block state. The transfer is fast when the interconnect and remote instance are healthy, but it is still coordination that does not exist in the same way in a single instance.

SELECT  inst_id,  instance_number,  instance_name,  host_name,  status,  thread#,  archiverFROM gv$instanceORDER BY inst_id;

SELECT inst_id,thread#,status,enabledFROM gv$threadORDER BY inst_id,thread#;SELECT inst_id,name,valueFROM gv$parameterWHERE name IN (  'cluster_database',  'instance_number',  'thread',  'undo_tablespace')ORDER BY inst_id,name;

On a healthy two-instance RAC database you expect two GV$INSTANCE rows and cluster-aware parameters/redo threads that distinguish instances. GV$ views aggregate instance-local V$ data through the cluster.

4. GCS/GES background processes expose the mechanism

SELECT  inst_id,  pname,  pid,  programFROM gv$processWHERE pname LIKE 'LM%'   OR pname IN ('LMS0','LMON','LMD0')ORDER BY inst_id,pname;

Process counts/names vary with workload/release. LMS processes serve global-cache messages and block transfers; LMON/LMD coordinate membership/resource management. Do not use a fixed expected process count as a health test.

5. RAC does not split one ordinary serial SQL statement across instances automatically

A client session connects to one instance for a request. The SQL optimizer may use intra-instance or RAC-aware parallel execution when configured/licensed/appropriate, but ordinary RAC does not mean “instance 1 runs half the SELECT and instance 2 runs the other half.” Adding an instance can improve concurrency or availability while a single poorly selective serial statement remains just as expensive—or becomes worse if it causes global block traffic.

6. Free baseline lab: prove the single-instance boundary

SELECT  database_role,  open_mode,  platform_nameFROM v$database;SELECT  inst_id,  instance_number,  instance_name,  host_name,  statusFROM gv$instance;SELECT  name,valueFROM v$parameterWHERE name IN ('cluster_database','instance_number')ORDER BY name;

On Free you expect one GV$INSTANCE row and CLUSTER_DATABASE=FALSE. That is useful baseline evidence, but it cannot reproduce Cache Fusion or GES/GCS contention.

7. Deliberately wrong: start a second Free database in the same logical environment

Oracle AI Database Free is explicitly single-installation/single-instance per logical environment. Trying to turn two Free instances on the same host/container/VM into “free RAC” violates the product boundary; current Free can raise ORA-00442: Oracle AI Database Free single instance violation error when another Free installation is started in the same logical environment.

8. Architecture worksheet from the current ServiceHub workload

SELECT  SYSTIMESTAMP AS captured_at,  MAX(CASE WHEN name='user commits' THEN value END) AS commits,  MAX(CASE WHEN name='redo size' THEN value END) AS redo_bytes,  MAX(CASE WHEN name='session logical reads' THEN value END) AS logical_readsFROM v$sysstatWHERE name IN (  'user commits',  'redo size',  'session logical reads');SELECT COUNT(*) AS user_sessionsFROM v$sessionWHERE type='USER';

Take two snapshots around a representative interval and derive commits/sec, redo bytes/sec and logical reads/sec. Add CPU, storage latency, connection count, hot-object evidence and availability requirements. RAC node count is an architecture result—not the starting assumption.

9. Production judgment

RAC is appropriate when multiple instances over one shared database materially improve node/instance availability and concurrent workload scale without unacceptable Cache Fusion coordination. It does not create a remote disaster copy, remove storage/network failure domains, or repair inefficient SQL automatically.

Current 26ai RAC is an extra-cost option on EE/EE-ES and included in BaseDB EE-EP/ExaDB; it is unavailable in Free. Grid Infrastructure must be installed first, and the Grid Infrastructure release must be the same as or newer than the highest RAC database release in the cluster. Lesson 2 adds the infrastructure/client layer that makes multiple instances usable: Clusterware resources, SCAN, VIPs and services.

Authoritative references

• Introduction to Oracle RAC — RAC, Grid Infrastructure, Cache Fusion, GCS/GES/GRD
• Oracle RAC Database Instance — instance/cache-fusion/interconnect model
• Monitoring Performance — RAC wait/resource diagnostics
• Licensing Information — RAC offering/option boundaries
• Licensing Restrictions for Free — single-instance and resource limits