A Note on the Version Number

Before anything else, clear up the confusion that trips up every DBA touching this release for the first time: Oracle AI Database 26ai reports its version as 23.26.x.x.x (for example, 23.26.1.0.0). "26ai" is the marketing name; 23.26 is the technical version — 26ai is a Release Update on the 23.x code line, not a separate 24/25/26 database kernel. When you connect with SQL*Plus and see Release 23.26.1.0.0 - Production, that is 26ai. The on-premises release for Linux x86-64 became available in January 2026.

This guide walks the full Oracle RAC 26ai installation on Linux, grounded in Oracle's official Real Application Clusters Installation Guide. It covers the sequence a DBA actually follows: prepare the cluster, install Grid Infrastructure, install the RAC database software, then create the database with DBCA. The prerequisites are the majority of the real work — get networking, storage, and user equivalence right and the installers are almost anticlimactic.

The Two Big Prerequisites Oracle Assumes

Oracle's RAC install guide assumes two things are already true before you run the database installer, and both are non-negotiable:

Grid Infrastructure must already be installed, at a version equal to or greater than the RAC version. RAC databases cannot function without Grid Infrastructure (GI) — which provides Oracle Clusterware, ASM, the cluster's virtual IPs, and the SCAN. The Clusterware release must be later than or equal to the Oracle AI Database software release you are installing. GI has its own installation guide and its own home, which must be separate from the database Oracle home.

A note on terminology for 26ai: starting with Oracle Grid Infrastructure 26ai, the Cluster Verification Utility (CVU) is renamed to Configuration Verification Utility — same tool, same cluvfy/runcluvfy.sh commands, new name. It still lives in the Grid home's bin directory.

Architecture in One Paragraph

Each node runs its own database instance, but all instances mount one shared database on shared storage (ASM disk groups on SAN/NFS/iSCSI LUNs visible to every node). Grid Infrastructure runs first and owns clusterware, ASM, VIPs, and SCAN. The database software and instances layer on top. Clients connect to the SCAN (Single Client Access Name), which load-balances across nodes and survives node failure. Three network layers matter: public (client traffic), private interconnect (cache fusion between nodes — dedicated, low-latency), and virtual IPs/SCAN (failover addresses).

Step 1: Confirm Hardware and OS Prerequisites

Prepare servers per the Grid Infrastructure Installation Guide for your platform. Each node needs at least 8 GB RAM (16 GB+ for production), and Oracle 26ai is certified on Red Hat Enterprise Linux 9 / Oracle Linux 9 (and Oracle Linux 10). Use identical server hardware on every node to simplify maintenance — asymmetry between nodes is a leading cause of intermittent RAC problems.

grep MemTotal /proc/meminfo        # >= 8 GB
grep SwapTotal /proc/meminfo
df -h /tmp                          # >= 1 GB free
cat /etc/oracle-release             # OL9 / OL10
uname -r

During installation, Oracle Universal Installer (OUI) detects when minimum requirements are not met and generates fixup scripts (runfixup.sh) that you run as root to finish incomplete system configuration.

Step 2: Plan the Network Layout

Per node you need: one public IP, one private IP (interconnect), and one virtual IP (VIP). Cluster-wide you need a SCAN name that resolves to three IPs via DNS round-robin. Document all of this before editing a single config file.

# Public
rac1     192.168.10.11
rac2     192.168.10.12
# VIP
rac1-vip 192.168.10.21
rac2-vip 192.168.10.22
# Private interconnect (separate, non-routable subnet)
rac1-priv 10.10.10.11
rac2-priv 10.10.10.12
# SCAN — one name, three IPs (DNS round-robin)
rac-scan  192.168.10.31, .32, .33

The private interconnect must be on a dedicated subnet with its own switch — cache fusion traffic sharing the public network is a classic performance killer. Note: a 26ai release-notes item advises ordering /etc/hosts entries with IPv6 first, then IPv4, if your environment is dual-stack.

Step 3: Configure /etc/hosts and Verify DNS

Populate public, VIP, and private entries identically in /etc/hosts on every node. Do not put the SCAN in /etc/hosts when using DNS — it can only hold one IP and defeats round-robin.

cat >> /etc/hosts <<'EOF'
192.168.10.11   rac1.example.com   rac1
192.168.10.12   rac2.example.com   rac2
192.168.10.21   rac1-vip.example.com  rac1-vip
192.168.10.22   rac2-vip.example.com  rac2-vip
10.10.10.11     rac1-priv.example.com rac1-priv
10.10.10.12     rac2-priv.example.com rac2-priv
EOF

# Verify SCAN resolves to three IPs and rotates
for i in 1 2 3; do nslookup rac-scan.example.com | grep Address; done

If the SCAN doesn't return three IPs or the order never rotates, fix DNS now — the installer's Configuration Verification will fail on SCAN otherwise.

Step 4: Create OS Groups and Users

Create the grid and oracle users with the standard OSDBA/OSASM group separation, using identical UIDs and GIDs across all nodes. On Oracle Linux, the oracle-database-preinstall RPM creates these for you and is strongly recommended.

groupadd -g 54321 oinstall
groupadd -g 54322 dba
groupadd -g 54323 asmdba
groupadd -g 54324 asmadmin
groupadd -g 54325 asmoper
groupadd -g 54327 backupdba
groupadd -g 54328 dgdba
groupadd -g 54329 kmdba
groupadd -g 54330 racdba

useradd -u 54331 -g oinstall -G asmadmin,asmdba,asmoper,dba grid
useradd -u 54321 -g oinstall -G dba,asmdba,backupdba,dgdba,kmdba,racdba oracle

Run these identically on every node. A UID mismatch between node1's grid and node2's grid is one of the most common — and most maddening — RAC install failures.

Step 5: Kernel Parameters and Shell Limits

Set the Oracle-required sysctl values and shell limits on all nodes. The oracle-database-preinstall-26ai RPM sets most of these automatically:

# Oracle Linux — the easy path (also creates users, sets limits & kernel params)
dnf install -y oracle-database-preinstall-26ai

# Verify the key limits took effect (log in as oracle, then):
ulimit -n    # nofile — should be 65536 hard
ulimit -u    # nproc  — should be 16384

If you configure kernel parameters manually, set fs.file-max, kernel.shmmax, kernel.shmall, kernel.sem, net.ipv4.ip_local_port_range, and the socket buffer sizes per the install guide, then apply with sysctl --system.

Step 6: Disable Interfering Services

Stop services that conflict with clusterware time sync and interconnect networking on all nodes:

# avahi hijacks multicast on the interconnect — must be off
systemctl disable --now avahi-daemon avahi-daemon.socket

# Time sync: either let Cluster Time Sync Service (CTSS) manage it,
# or keep chrony configured with the -x flag (no slewing)
systemctl disable --now chronyd    # if letting CTSS handle time

If you keep chronyd, add -x to its options so it doesn't slew the clock — CTSS and a slewing chrony fight each other. The avahi-daemon running is flagged by Configuration Verification (PRVG-1359/PRVG-1360), so disable it before you run the checks.

Step 7: Provision and Label Shared Storage

Present the same LUNs to every node. Every shared disk must be visible on all nodes, and the ASM disks must have correct ownership and permissions. In Oracle 26ai, note the ASM disk group ownership convention uses asmdba for the disk devices (verify against your GI configuration — the OSASM/OSDBA-for-ASM group separation is set during GI install).

# Confirm all nodes see the same LUNs
lsblk
ls -l /dev/disk/by-id/

# udev rules for stable, correctly-owned ASM devices
cat > /etc/udev/rules.d/99-oracle-asmdevices.rules <<'EOF'
KERNEL=="sd?1", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$parent", \
  RESULT=="36001405xxxxxxxx", SYMLINK+="oracleasm/disk1", OWNER="grid", GROUP="asmadmin", MODE="0660"
EOF
udevadm control --reload-rules && udevadm trigger
ls -l /dev/oracleasm/

Plan disk groups: OCR/voting (needs normal or high redundancy for quorum — three failure groups), plus DATA and RECO (recovery area). Wrong disk ownership here is the single most common ASM disk-discovery failure. Oracle recommends ASM Filter Driver (AFD) as the current best practice for disk management.

Step 8: Configure SSH User Equivalence

Grid Infrastructure and the database installer need passwordless SSH between all nodes for both grid and oracle users, in both directions, including node-to-self. The installer can configure this automatically, but the account must be permitted to set up passwordless SSH.

su - grid
ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa
for n in rac1 rac2; do ssh-copy-id grid@$n; done
# Verify every pair returns hostname with NO password prompt
for n in rac1 rac2; do ssh $n hostname; done

Repeat for the oracle user. Test all directions: rac1->rac2, rac2->rac1, and each node to itself. A single missing pair fails the cluster install. If you cannot turn off stty commands or have restrictions preventing automatic SSH setup from the installer, configure SSH manually before starting.

Step 9: Run Configuration Verification (Pre-Check)

Before installing anything, run the Configuration Verification Utility (formerly CVU) from the Grid home to catch prerequisite gaps. Fix every failure — manually or with the generated fixup script — before proceeding.

su - grid
cd /u01/app/26ai/grid          # your GI home
./runcluvfy.sh stage -pre crsinst -n rac1,rac2 -verbose

Read every FAILED and WARNING. Configuration Verification finds the /etc/hosts typo, the missing package, the UID mismatch, and the SCAN problem before the real installer does. Do not proceed with unresolved failures.

Step 10: Install Grid Infrastructure

Grid Infrastructure ships as an image you extract directly into the GI home, then run gridSetup.sh. Extract on the first node — the installer propagates to the others.

su - grid
mkdir -p /u01/app/26ai/grid
cd /u01/app/26ai/grid
unzip -q /tmp/grid_home.zip
./gridSetup.sh

Choose "Configure Oracle Grid Infrastructure for a New Cluster," enter your cluster name and SCAN, map the network interfaces (public / ASM & private interconnect), create the OCR/voting ASM disk group from your prepared disks, and set the ASM passwords. When prompted, run orainstRoot.sh and root.sh as root — on the first node, wait for it to complete, then the second node. Never run root.sh on both nodes simultaneously. Verify with crsctl check cluster -all and crsctl stat res -t — everything should be ONLINE.

Step 11: Extract the RAC Database Software

Now the database tier. Switch to the oracle user, download the database installation image (db_home.zip), and extract it directly into a new Oracle home. The Oracle home must be different from the Grid home.

su - oracle
mkdir -p /u01/app/oracle/product/23.0.0/dbhome_1
chgrp oinstall /u01/app/oracle/product/23.0.0/dbhome_1
cd /u01/app/oracle/product/23.0.0/dbhome_1
unzip -q /tmp/db_home.zip

Oracle requires the home path to follow Optimal Flexible Architecture, and neither the Oracle home nor Oracle base (nor any parent directory up to root) can be a symlink. Unzip the image only into this home directory.

Step 12: Launch the Database Installer (GUI)

RAC database installation is a two-step process: install the software (this step), then create the database with DBCA (later). Start the installer from the Oracle home directory — not from $ORACLE_HOME/oui/bin.

cd /u01/app/oracle/product/23.0.0/dbhome_1
./runInstaller

Walk the screens:

Software-only-then-DBCA gives cleaner control and easier troubleshooting than creating the database inline.

Step 13: Install the Software Silently (CLI Alternative)

For unattended or scripted installs, skip the GUI and use runInstaller -setupDBHome with the OS group flags and node list:

cd /u01/app/oracle/product/23.0.0/dbhome_1
./runInstaller -setupDBHome \
  -OSDBA dba -OSBACKUPDBA backupdba -OSDGDBA dgdba \
  -OSKMDBA kmdba -OSRACDBA racdba -OSOPER oper \
  -ORACLE_BASE /u01/app/oracle \
  -clusterNodes rac1,rac2 \
  -silent

This is the reproducible path for building identical clusters — capture it in your provisioning scripts so every environment is bit-for-bit consistent.

Step 14: Run the Database Root Scripts

The installer pauses for root.sh on each node (or runs it automatically if you supplied credentials in Step 12). If running manually, do node1 first, then node2:

# node1 as root
/u01/app/oracle/product/23.0.0/dbhome_1/root.sh
# then node2 as root
/u01/app/oracle/product/23.0.0/dbhome_1/root.sh

These are quick — they mostly set permissions and register the home. Confirm each completes cleanly before the next.

Step 15: Create the RAC Database with DBCA (GUI)

Run DBCA from $ORACLE_HOME/bin to create the clustered database. DBCA is cluster-aware and provisions instances on all nodes.

su - oracle
cd /u01/app/oracle/product/23.0.0/dbhome_1/bin
./dbca

Key choices: database type "Oracle Real Application Clusters (RAC) database"; Admin-Managed configuration; select all nodes; ASM storage with DATA for datafiles and RECO for the recovery area; enable archivelog mode (mandatory for production); and — since 26ai is multitenant by default — create it as a container database (CDB) with one or more PDBs.

Step 16: Create the Database Silently (CLI Alternative)

The scripted equivalent of Step 15 — this is the exact dbca -silent -createDatabase form from Oracle's guide, creating a container database with PDBs on ASM. It sets SYS/SYSTEM/DBSNMP to a placeholder password you must change:

$ORACLE_HOME/bin/dbca -silent -createDatabase -templateName "General_Purpose.dbc" \
  -gdbName racdb.example.com -sid racdb \
  -storageType ASM -diskGroupName DATA -recoveryAreaDestination RECO \
  -nodelist rac1,rac2 -characterset WE8MSWIN1252 \
  -databaseType "MULTIPURPOSE" \
  -createAsContainerDatabase true -numberofPDBs 2 -pdbName racpdb

-nodelist rac1,rac2 is what makes it a RAC database — DBCA creates one instance per node (racdb1 on rac1, racdb2 on rac2), registers them with clusterware, and configures the SCAN listeners to route to them. Change the default passwords immediately after creation.

Step 17: Verify the RAC Database

Confirm both instances are up and registered with clusterware:

su - oracle
# Database + instance status via srvctl
srvctl status database -d racdb
# Should list both instances running on their nodes
sqlplus / as sysdba
SQL> SELECT inst_id, instance_name, host_name, status FROM gv$instance;
SQL> SELECT name, open_mode, cdb FROM v$database;
SQL> SHOW PDBS;
# SCAN listener routing
lsnrctl status LISTENER_SCAN1

gv$instance (global v$, spanning all nodes) should return one row per node, all OPEN. If only one instance appears, the second didn't start — check its alert log and clusterware resource status.

Step 18: Validate Failover and Connectivity

The whole point of RAC is surviving node loss — test it before declaring victory. Connect through the SCAN, confirm load balancing, then simulate a node failure:

# Connect via SCAN (client-side) — should distribute across instances
sqlplus system/[email protected]:1521/racpdb

srvctl status service -d racdb

# Controlled failover: stop one instance, confirm the DB stays open
srvctl stop instance -d racdb -i racdb2
srvctl status database -d racdb
# Restart it
srvctl start instance -d racdb -i racdb2

A clean install where you never tested failover is a gamble, not a cluster. Confirm connections survive an instance going down and rebalance when it returns.

What's New in RAC 26ai Worth Knowing

Two 26ai RAC features change day-two operations meaningfully:

Two-Stage Rolling Patching separates patch application from patch activation, enabling certain patches that were previously "non-rolling" to be applied in a rolling fashion — less downtime for maintenance that used to require a full outage. It works with existing tooling: Fleet Patching and Provisioning (FPP), OPatchAuto, and OPatch.

Local rolling database maintenance automatically creates a second instance on the same host and relocates sessions to it, reducing the network and CPU overhead of session relocation during maintenance.

And because 26ai is Oracle AI Database, RAC now natively supports AI Vector Search workloads across cluster instances — the vector index and similarity search scale across nodes like any other workload, which matters if you are running RAG or embedding search on the same cluster as your OLTP.

Common Failures You Will Actually Hit

root.sh fails on the first node (CRS-4124 / OHASD startup failed) — almost always shared storage (voting disk not visible or wrong ownership) or the private interconnect (nodes can't reach each other on the private subnet). Check the clusterware logs under the GI home and confirm ASM disk ownership.

PRVG-10048 "name not resolved" or SCAN failures during Configuration Verification — DNS resolution for a node, VIP, or the SCAN is incomplete. Every public name, VIP, and all three SCAN IPs must resolve.

PRVG-1359/1360 avahi-daemon flagged — the avahi daemon is still running; disable it (Step 6) and re-run the checks.

ASM disks don't appear in the installer — discovery string or disk permissions. Disks must be owned correctly (grid, ASM group), mode 0660, and the ASM discovery string must match your device labels.

Second instance won't start after DBCA — usually the spfile in ASM isn't readable by node2, or node2's listener/VIP isn't up. Check srvctl status nodeapps and the second instance's alert log.

After the Install: Ongoing Health

A freshly installed RAC cluster is the beginning, not the end. Cache fusion latency, interconnect health, ASM disk group free space, unbalanced services across nodes, and clusterware resource state all drift over time — and single-instance monitoring tools miss the cluster-aware signals entirely. Watching gv$ views, interconnect block-transfer rates, and CRS resource health continuously is what separates a RAC cluster that quietly does its job from one that fails over at 3 a.m. while nobody noticed it was already degraded.