# Grid Infrastructure Installation and Upgrade Guide

This file contains the text from each Grid Infrastructure Installation and Upgrade Guide article landing page, release 26ai.

# Oracle Grid Infrastructure Installation Checklist

Use checklists to plan and carry out Oracle Grid Infrastructure (Oracle Clusterware and Oracle Automatic Storage Management) installation.

Oracle recommends that you use checklists as part of your installation planning process. Using this checklist can help you to confirm that your server hardware and configuration meet minimum requirements for this release, and to ensure you carry out a successful installation.

## Server Hardware Checklist For Oracle Grid Infrastructure

Verify that each server operates at runlevel 3 or 5, provides at least 8 GB of RAM, and supports a minimum 1024 × 768 display for graphical Oracle Universal Installer use. A graphics card is unnecessary for silent installations or remote graphical access such as VNC. Configure IPMI and the baseboard management controller on every cluster node, with administrator credentials available; the IPMI driver must be configured consistently on all or none of the nodes.

Read More: [Server Hardware Checklist For Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-installation-checklist/server-hardware-checklist-for-oracle-grid-infrastructure.html)

## Operating System Checklist For Oracle Grid Infrastructure And Oracle Rac

Install OpenSSH and the required platform packages, using identical supported operating-system kernels and packages across all cluster nodes. Supported platforms include specified Oracle Linux, Red Hat Enterprise Linux, and SUSE Linux Enterprise Server releases, with Oracle recommending Oracle Linux 8.6 or later using UEK7 where applicable. On Oracle Linux, use the appropriate Oracle AI Database preinstallation RPM when possible, verify virtualization support against Oracle’s compatibility guidance, and disable Transparent HugePages in favor of standard HugePages.

Read More: [Operating System Checklist For Oracle Grid Infrastructure And Oracle Rac](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-installation-checklist/operating-system-checklist-for-oracle-grid-infrastructure-and-oracle-rac.html)

## Server Configuration Checklist For Oracle Grid Infrastructure

Provide at least 1 GB in /tmp, configure swap between 4 and 16 GB equal to RAM and cap it at 16 GB above that, reducing available RAM by HugePages allocation when calculating swap. Allocate HugePages for the planned database SGAs, use an Optimal Flexible Architecture layout, and restrict Oracle home paths, owners, and related directories to ASCII characters. Configure locale and consistent time zones, synchronize cluster nodes with operating-system NTP, and note that CTSS is desupported. Ensure /dev/shm is a writable, executable tmpfs without noexec or nosuid restrictions, and ensure Oracle base, Oracle home, and all parent directories are not symbolic links.

Read More: [Server Configuration Checklist For Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-installation-checklist/server-configuration-checklist-for-oracle-grid-infrastructure.html)

## Network Checklist For Oracle Grid Infrastructure

Provide redundant public and private switching and network interfaces where possible, using TCP/IP and at least 1 GbE; Oracle recommends 25 GbE or higher for NVMe-oF. The private interconnect must support UDP, and properly tested, end-to-end Jumbo Frames are recommended. Oracle Flex ASM may share Clusterware private networks or use dedicated TCP networks. Plan a globally unique cluster name of no more than 15 valid hostname characters, configure GNS and delegated DNS when used, or configure SCAN to resolve to three DNS addresses manually. Without GNS, define public, private, and publicly accessible virtual IP names and addresses for every node in DNS and/or /etc/hosts as appropriate.

Read More: [Network Checklist For Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-installation-checklist/network-checklist-for-oracle-grid-infrastructure.html)

## User Environment Configuration Checklist For Oracle Grid Infrastructure

Confirm the oraInventory directory and OINSTALL group are available and usable as the primary group for all Oracle software owners. Create the required operating-system users and groups with ASCII-only names, preserve any required daemon users, and apply resource limits. Unset inherited Oracle environment variables such as ORACLE\_HOME, ORA\_NLS10, TNS\_ADMIN, and ORA\_CRS\_HOME before installation. Configure the oracle or grid user with umask 022 and DISPLAY, then select manual root-script execution or delegated execution using consistent root credentials or a properly authorized sudo account on every cluster node.

Read More: [User Environment Configuration Checklist For Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-installation-checklist/user-environment-configuration-checklist-for-oracle-grid-infrastructure.html)

## Storage Checklist For Oracle Grid Infrastructure

Allocate at least 12 GB for the Grid home, preferably 100 GB to accommodate patches, plus at least 10 GB for Oracle AI Database Enterprise Edition and any additional space required by the cluster configuration. Select shared Oracle ASM or shared file-system storage as appropriate, ensuring the Grid installation owner can write to the configured ASM paths and that storage is locally available across all nodes. Clusterware files, including voting files and Oracle Cluster Registry files, must reside on shared storage accessible to every cluster member.

Read More: [Storage Checklist For Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-installation-checklist/storage-checklist-for-oracle-grid-infrastructure.html)

## Cluster Deployment Checklist For Oracle Grid Infrastructure

Choose the deployment model that matches the intended workload: a cluster managing Oracle RAC databases, a minimally configured cluster managing generic applications, or an Oracle Extended Cluster spanning multiple sites with separate storage at each site. Ensure the selected design hosts Grid Infrastructure services and Oracle ASM locally while providing direct access to the required storage.

Read More: [Cluster Deployment Checklist For Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-installation-checklist/cluster-deployment-checklist-for-oracle-grid-infrastructure.html)

## Installer Planning Checklist For Oracle Grid Infrastructure

Before installation, review platform release notes and licensing terms, run Oracle Universal Installer with its integrated CVU checks and fixup scripts, and use Oracle ORAchk for runtime or upgrade-readiness assessments. Prevent cleanup cron jobs from running during installation, prepare My Oracle Support credentials for updates and security configuration, and review active Oracle processes. Single-instance databases without ASM may remain running, but existing ASM instances must be stopped, while Oracle RAC databases require a rolling node-by-node shutdown during Clusterware upgrades.
Read More: [Installer Planning Checklist For Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-installation-checklist/installer-planning-checklist-for-oracle-grid-infrastructure.html)


# Checking And Configuring Server Hardware For Oracle Grid Infrastructure

Verify that servers where you install Oracle Grid Infrastructure meet the minimum requirements for installation.

This section provides minimum server requirements to complete installation of Oracle Grid Infrastructure. It does not provide system resource guidelines, or other tuning guidelines for particular workloads.

## Logging In to a Remote System Using X Window System

This procedure explains how to run Oracle Universal Installer on a remote server when direct GUI login is unavailable. Start an X Window System session, permit the remote host with `xhost`, connect using `ssh -Y` when installing remotely, and switch to `root` when required; repeat the process for each installation owner account, such as `oracle` or `grid`.

Read More: [Logging In to a Remote System Using X Window System](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/checking-and-configuring-server-hardware-for-oracle-grid-infrastructure/logging-in-to-a-remote-system-using-x-window-system.html)

## Checking Server Hardware and Memory Configuration

Use system commands to verify physical RAM, swap space, `/tmp` capacity, available memory and swap, processor architecture, and `/dev/shm` sizing before installation. Add memory or swap, free `/tmp` space or redirect temporary directories with `TMP` and `TMPDIR`, confirm the expected architecture such as `x86_64`, and ensure shared memory is properly mounted; preserve Oracle-specific temporary directories when cleaning `/tmp`.

Read More: [Checking Server Hardware and Memory Configuration](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/checking-and-configuring-server-hardware-for-oracle-grid-infrastructure/checking-server-hardware-and-memory-configuration.html)

## Setting Remote Display and X11 Forwarding Configuration

Configure the `DISPLAY` environment variable according to the shell when using a remote terminal, typically targeting the local display with a value such as `hostname:0`. To prevent installation failures caused by X11 forwarding, set `ForwardX11 no` in the installation owner’s user-level SSH configuration and secure the `.ssh` directory and its contents for that account.

Read More: [Setting Remote Display and X11 Forwarding Configuration](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/checking-and-configuring-server-hardware-for-oracle-grid-infrastructure/setting-remote-display-and-x11-forwarding-configuration.html)

## Preventing Installation Errors Caused by Terminal Output Commands

During Grid Infrastructure installation, OUI uses SSH across nodes, so shell startup files such as `.bashrc` and `.cshrc` must not emit terminal output through commands like `stty` or `xtitle`. Guard such commands with interactive-terminal checks appropriate to Bourne-compatible or C shells; otherwise, OUI may report an error and stop the installation.

Read More: [Preventing Installation Errors Caused by Terminal Output Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/checking-and-configuring-server-hardware-for-oracle-grid-infrastructure/preventing-installation-errors-caused-by-terminal-output-commands.html)

## About Installing Oracle AI Database Software on Oracle Exadata Database Machine

Oracle recommends using Oracle Exadata Deployment Assistant to install Grid Infrastructure and Oracle AI Database on Exadata. Manual installation is possible, but the Exadata system software already provides the required Linux packages and configuration, so packages, RPMs, and Linux parameters should not be installed, upgraded, or modified; compatibility must be verified against the supported Oracle AI Database and Exadata software versions.
Read More: [About Installing Oracle AI Database Software on Oracle Exadata Database Machine](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/checking-and-configuring-server-hardware-for-oracle-grid-infrastructure/about-installing-oracle-ai-database-software-on-oracle-exadata-database-machine.html)


# Automatically Configuring Oracle Linux with Oracle AI Database Preinstallation RPM

Use Oracle AI Database Preinstallation RPM to simplify operating system configuration in preparation for Oracle software installations.

Oracle recommends that you install Oracle Linux and use Oracle AI Database Preinstallation RPM to configure your operating systems for Oracle AI Database and Oracle Grid Infrastructure installations.

## About the Oracle AI Database Preinstallation RPM

The Oracle AI Database Preinstallation RPM simplifies preparation of Oracle Linux or Red Hat Enterprise Linux systems for Oracle AI Database and Grid Infrastructure by installing required packages, creating the standard Oracle user and groups, configuring kernel and driver parameters, setting resource limits, and enabling recommended transparent huge pages behavior. Install it only once during the initial Oracle software installation, do not use it on engineered systems, and manually configure additional software owners because its limits and kernel settings target the oracle account. The RPM provides X11 client libraries but not an X Window System server.

Read More: [About the Oracle AI Database Preinstallation RPM](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/automatically-configuring-oracle-linux-with-oracle-ai-database-preinstallation-rpm/about-the-oracle-ai-database-preinstallation-rpm.html)

## Overview of Oracle Linux Configuration with Oracle AI Database Preinstallation RPM

The Oracle AI Database Preinstallation RPM automates required package installation and operating system configuration for Oracle AI Database and Grid Infrastructure on Oracle Linux. Configure it only during the first installation and exclude engineered systems. The overall process includes installing and updating Oracle Linux, registering with ULN or configuring the Oracle Linux yum repository, installing the release-specific RPM, creating consistent role-separated users and groups, configuring cluster networking, and preparing shared storage before installing Grid Infrastructure and the database.

Read More: [Overview of Oracle Linux Configuration with Oracle AI Database Preinstallation RPM](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/automatically-configuring-oracle-linux-with-oracle-ai-database-preinstallation-rpm/overview-of-oracle-linux-configuration-with-oracle-ai-database-preinstallation-rpm.html)

## Installing the Oracle AI Database Preinstallation RPM Using ULN

To install the preinstallation RPM through ULN, obtain the latest Oracle Linux update, register each server with ULN, and install the release package as root using `dnf install oracle-ai-database-preinstall-26ai` on Oracle Linux 8, 9, or 10. The RPM creates the standard Oracle installation owner and groups and applies required kernel settings; administrators should review the generated log, repeat the procedure on every cluster server, and may optionally enable Ksplice when supported by their subscription.

Read More: [Installing the Oracle AI Database Preinstallation RPM Using ULN](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/automatically-configuring-oracle-linux-with-oracle-ai-database-preinstallation-rpm/installing-the-oracle-ai-database-preinstallation-rpm-using-uln.html)

## Installing the Oracle AI Database Preinstallation RPM During an Oracle Linux Installation

During a new Oracle Linux installation, select customized software packages, choose the server and system administration tools categories, and include the release-appropriate Oracle AI Database Preinstallation RPM for Oracle Linux 8, 9, or 10. Complete the installation on each cluster node; Oracle Linux then creates the standard Oracle owner and groups and applies required kernel configuration. If a suitable current RPM is unavailable in the installer, install it manually after the operating system installation.

Read More: [Installing the Oracle AI Database Preinstallation RPM During an Oracle Linux Installation](https://orahub.oci.oraclecorp.com/db-ua-dev/text-editor-poc/-/tree/no-doc-repo/automatically_configuring_oracle_linux_with_oracle_ai_database_preinstallation_rpm/26ai/installing_the_oracle_ai_database_preinstallation_rpm_during_an_oracle_linux_installation.md?ref_type=heads)

## Installing Oracle Oracle AI Database Preinstallation RPM Using the Oracle Linux Yum Server

Install Oracle Linux using the official documentation, apply current security and bug-fix updates with `yum update`, restart the system, and install the preinstallation RPM as root with `dnf install oracle-ai-database-preinstall-26ai` on Oracle Linux 8, 9, or 10. The RPM creates the standard Oracle owner and groups and configures required kernel settings; additional users and groups must be created manually when job-role separation is needed.

Read More: [Installing Oracle Oracle AI Database Preinstallation RPM Using the Oracle Linux Yum Server](https://orahub.oci.oraclecorp.com/db-ua-dev/text-editor-poc/-/blob/no-doc-repo/CWLIN%2Fautomatically_configuring_oracle_linux_with_oracle_ai_database_preinstallation_rpm%2F26ai%2Finstalling_oracle_oracle_ai_database_preinstallation_rpm_using_the_oracle_linux_yum_server.md?ref=no-doc-repo)

## Configure Additional Operating System Features

Before installing Oracle software, configure any additional operating system features required by the environment, such as IPMI or programming language and development environments. Review the relevant preinstallation guidance and complete the feature-specific configuration before beginning the database or Grid Infrastructure installation.
Read More: [Configure Additional Operating System Features](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/automatically-configuring-oracle-linux-with-oracle-ai-database-preinstallation-rpm/configure-additional-operating-system-features.html)


# Configuring Operating Systems for Oracle Grid Infrastructure On Linux

## Guidelines for Linux Operating System Installation

Before installing Oracle software, complete the required Linux operating system configuration, hardware checks, and security reviews, following the supported distribution guidance and vendor security practices.

Read More: [Guidelines for Linux Operating System Installation](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/guidelines-for-linux-operating-system-installation.html)

## Completing a Minimal or Default Linux Installation

Install either a minimal or default Linux configuration. Minimal installations require the Oracle Linux preinstallation RPM or manual package installation, while default installations provide most dependencies and are recommended when the preinstallation RPM is not used; avoid customizing default package selections.

Read More: [Completing a Minimal or Default Linux Installation](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/completing-a-minimal-or-default-linux-installation.html)

## About Oracle Linux with the Unbreakable Enterprise Kernel

Oracle recommends the Unbreakable Enterprise Kernel (UEK) for Oracle Linux because it provides enterprise optimizations, stability, and performance, and is the standard kernel used for Oracle products, Exadata, benchmarks, and preinstallation tooling. A RHEL-compatible kernel remains available when strict compatibility is required, and Ksplice can update kernels without restarting.

Read More: [About Oracle Linux with the Unbreakable Enterprise Kernel](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/about-oracle-linux-with-the-unbreakable-enterprise-kernel.html)

## Restrictions for HugePages and Transparent HugePages Configurations

Use standard HugePages for Oracle databases and configure Transparent HugePages as `madvise` on UEK7 and later rather than disabling them. The preinstallation RPM applies this setting automatically; account for non-swappable HugePages memory when calculating available RAM and swap.

Read More: [Restrictions for HugePages and Transparent HugePages Configurations](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/restrictions-for-hugepages-and-transparent-hugepages-configurations.html)

## Configuring HugePages on Linux

Linux HugePages can improve Oracle performance by reducing page-management overhead and increasing TLB hit rates. Reserve at least 30% of RAM for standard pages and no more than 70% for HugePages, then configure kernel support, Oracle user memlock limits, the Oracle group’s shared-memory permission, and persistent HugePages settings; calculate capacity after databases are created and verify allocation after restarting instances.

Read More: [Configuring HugePages on Linux](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/configuring-hugepages-on-linux.html)

## Setting Transparent HugePages to madvise

Configure Transparent HugePages to `madvise` by adding the parameter to the GRUB kernel command line, regenerating the appropriate GRUB configuration, and restarting the system or applying the setting immediately through the kernel interface. Verify the active setting shows `madvise` as selected.

Read More: [Setting Transparent HugePages to madvise](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/setting-transparent-hugepages-to-madvise.html)

## Reviewing Operating System and Software Upgrade Best Practices

Before upgrades, record current versions, patches, and configuration, review the applicable upgrade documentation, and back up databases. Oracle ASM supports rolling upgrades for RAC with restrictions, while operating system migrations can use manual file and control-file procedures or Data Pump export and import; for Oracle AI Database 26ai, AutoUpgrade and Replay Upgrade are the supported upgrade methods.

Read More: [Reviewing Operating System and Software Upgrade Best Practices](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/reviewing-operating-system-and-software-upgrade-best-practices.html)

## About Installation Fixup Scripts

Oracle Universal Installer can generate `runfixup.sh` scripts to correct certain missing prerequisites, including kernel parameters, inventory permissions, group memberships, and shell limits, without requiring a restart. Fixup scripts do not replace complete prerequisite verification, and CVU can perform additional automated or manual checks for Grid Infrastructure and RAC installations.

Read More: [About Installation Fixup Scripts](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/about-installation-fixup-scripts.html)

## About Automatic Self Correction

Automatic Self Correction uses CVU to identify and correct fixable Oracle Clusterware configuration issues across applicable nodes without user intervention. Enable it during Grid Infrastructure installation; any correction requiring a reboot is recorded in the CRS alert log.

Read More: [About Automatic Self Correction](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/about-automatic-self-correction.html)

## Additional Drivers and Software Packages for Linux

Optional Linux components include the latest Linux-PAM library for external scheduler authentication, OCFS2 for supported Oracle Linux shared-disk deployments, required Messaging Gateway fixes when applicable, unixODBC 2.3.4 or later for ODBC, LDAP packages for LDAP-dependent utilities, and platform-specific Java, compiler, COBOL, archive, and browser requirements. OCFS2 and Messaging Gateway are not supported on Linux for Arm, and the JDBC OCI Type 2 driver is deprecated in Oracle AI Database 26ai.

Read More: [Additional Drivers and Software Packages for Linux](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/additional-drivers-and-software-packages-for-linux.html)

## Checking Kernel and Package Requirements for Linux

Verify the installed Linux distribution, kernel release, and required RPM packages using release-information, `uname`, and RPM query commands. Compare versions with Oracle’s minimum requirements and install missing or outdated packages from the Linux distributor before proceeding.

Read More: [Checking Kernel and Package Requirements for Linux](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/checking-kernel-and-package-requirements-for-linux.html)

## Setting Clock Source for VMs on Linux x86-64

For Linux x86-64 virtual machines, Oracle recommends using the `tsc` clock source when available. Check supported sources, select `tsc`, verify it is active, and add `clocksource=tsc` to the GRUB kernel command line so the setting persists across reboots.

Read More: [Setting Clock Source for VMs on Linux x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/setting-clock-source-for-vms-on-linux-x86-64.html)

## Installing the cvuqdisk RPM for Linux

Install the hardware-appropriate `cvuqdisk` RPM on every cluster node so CVU can discover shared disks. Remove any older version, set `CVUQDISK_GRP` to the owning group such as `oinstall`, and install the package as root from the Grid Infrastructure home’s `cv/rpm` directory.

Read More: [Installing the cvuqdisk RPM for Linux](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/installing-the-cvuqdisk-rpm-for-linux.html)

## Enabling the Name Service Cache Daemon

Enable and start the Name Service Cache Daemon to improve Oracle Clusterware tolerance of network failures involving NAS devices or NFS mounts. Configure it to start at the required run levels, start or restart the service, and verify its active status with the applicable service-management command.

Read More: [Enabling the Name Service Cache Daemon](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/enabling-the-name-service-cache-daemon.html)

## Using Automatic SSH Configuration During Installation

Configure passwordless SSH and SFTP between all cluster nodes because Oracle Universal Installer, configuration assistants, and Enterprise Manager require noninteractive remote access. OUI can configure SSH automatically after profile commands that produce login output are removed; if necessary, set `LoginGraceTime 0` in the SSH daemon configuration to prevent remote connection closures during installation.

Read More: [Using Automatic SSH Configuration During Installation](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/using-automatic-ssh-configuration-during-installation.html)

## Verifying the Disk Input Output Scheduler on Linux 8 and Later Systems

Check the disk I/O scheduler on every cluster node and consult the storage vendor for the appropriate configuration. Oracle generally recommends `mq-deadline` for rotational disks and `none` for SSDs and NVMe devices when using Oracle ASM on supported Linux distributions.

Read More: [Verifying the Disk Input Output Scheduler on Linux 8 and Later Systems](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/verifying-the-disk-input-output-scheduler-on-linux-8-and-later-systems.html)

## Setting Network Time Protocol for Cluster Time Synchronization

Synchronize all cluster nodes with an operating-system time service such as `chronyd` or `ntpd`, because CTSS is desupported in Oracle AI Database 26ai. Ensure clocks and time-zone settings are consistent, verify synchronization with CVU, and stop and disable NTP services only when the installation procedure specifically requires their deactivation.

Read More: [Setting Network Time Protocol for Cluster Time Synchronization](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/setting-network-time-protocol-for-cluster-time-synchronization.html)

## Verifying Digital Signature and Integrity of Installation Archive Files

Oracle AI Database 26ai installation archives are digitally signed and should be verified before extraction or deployment. Use Java `jarsigner -verify` for a quick check, or add verbose and certificate options to inspect signer, certificate, timestamp, digest, and signature details; successful validation reports that the archive is verified.

Read More: [Verifying Digital Signature and Integrity of Installation Archive Files](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-operating-systems-for-oracle-grid-infrastructure-on-linux/verifying-digital-signature-and-integrity-of-installation-archive-files.html)


# Operating System Requirements for x86-64 Linux Platforms

## About Operating System Requirements for x86-64 Linux Platforms

Before installing Oracle AI Database or Oracle Grid Infrastructure on x86-64 Linux, verify the supported distribution, kernel, packages, and software requirements for the intended products. Requirements may change after publication, so consult the current certification matrix, and allow Oracle Universal Installer to validate prerequisites. All cluster members must use the same operating system version unless undergoing an upgrade.

Read More: \[About Operating System Requirements for x86-64 Linux Platforms\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/about-operating-system-requirements-for-x86-64-linux-platforms.html)

## General Guidelines for Operating System Packages

Oracle recommends Oracle Linux with the Oracle AI Database Preinstallation RPM, which configures the system and installs required dependencies. Interactive installation requires an X Window System package such as libX, while gcc and gcc-c++ are not required. These requirements do not apply to Engineered Systems, which provide their own supported operating system and packages.

Read More: \[General Guidelines for Operating System Packages\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/general-guidelines-for-operating-system-packages.html)

## Supported Oracle Linux 10 Distributions for x86-64

Oracle Linux 10 requires OpenSSH and, beginning with Oracle AI Database 26ai Release Update 23.26.2, supports UEK 8 kernel 6.12.0-104.43.4.2 or later and Red Hat Compatible Kernel 6.12.0-55.40.1.0.1 or later. Enable the Oracle Linux 10 repository and install the oracle-ai-database-preinstall-26ai RPM to configure required packages; optional packages support IPMI, RAC or Clusterware, ACFS, and Database Client installations.

Read More: \[Supported Oracle Linux 10 Distributions for x86-64\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/supported-oracle-linux-10-distributions-for-x86-64.html)

## Supported Oracle Linux 9 Distributions for x86-64

Oracle Linux 9 requires OpenSSH and supports Oracle Linux 9.2 with UEK 7 kernel 5.15.0-201.135.6 or later, the corresponding Red Hat Compatible Kernel 5.14.0-284.30.1 or later, and, from Release Update 23.26.2, Oracle Linux 9.6 with UEK 8 kernel 6.12.0-1.23.3.2 or later. The oracle-ai-database-preinstall-26ai RPM installs and configures required dependencies, while optional packages support IPMI, RAC or Clusterware, ACFS, and Database Client use.

Read More: \[Supported Oracle Linux 9 Distributions for x86-64\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/supported-oracle-linux-9-distributions-for-x86-64.html)

## Supported Oracle Linux 8 Distributions for x86-64

Oracle Linux 8 requires OpenSSH and supports release 8.6 with UEK 6 kernel 5.4.17-2136.312.3.4 or later or the Red Hat Compatible Kernel 4.18.0-372.26.1.0.1 or later; UEK 7 is strongly recommended, with Oracle Linux 8.8 and kernel 5.15.0-202.135.2 or later supported from Release Update 23.5. The oracle-ai-database-preinstall-26ai RPM supplies required packages and configuration, with optional packages for IPMI, Database Client, RAC or Clusterware, and ACFS.

Read More: \[Supported Oracle Linux 8 Distributions for x86-64\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/supported-oracle-linux-8-distributions-for-x86-64.html)

## Supported Red Hat Enterprise Linux 10 Distributions for x86-64

Red Hat Enterprise Linux 10 requires OpenSSH and, beginning with Oracle AI Database 26ai Release Update 23.26.2, kernel 6.12.0-55.40.1.0.1.el10\_0 or later. Install the latest vendor-provided core, compiler-runtime, X11, security-policy, storage, and system utility packages, with ipmiutil, net-tools, and nfs-utils available optionally for IPMI, RAC or Clusterware, and ACFS; consult the applicable patches and known-issues guidance.

Read More: \[Supported Red Hat Enterprise Linux 10 Distributions for x86-64\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/supported-red-hat-enterprise-linux-10-distributions-for-x86-64.html)

## Supported Red Hat Enterprise Linux 9 Distributions for x86-64

Red Hat Enterprise Linux 9 requires OpenSSH and version 9.2 with kernel 5.14.0-284.30.1.el9\_2 or later. Install the latest required development, runtime, X11, RDMA, security-policy, storage, and system utility packages from the vendor repositories. Optional packages support IPMI, Database Client, RAC or Clusterware, and ACFS deployments.

Read More: \[Supported Red Hat Enterprise Linux 9 Distributions for x86-64\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/supported-red-hat-enterprise-linux-9-distributions-for-x86-64.html)

## Supported Red Hat Enterprise Linux 8 Distributions for x86-64

Red Hat Enterprise Linux 8 requires OpenSSH and version 8.6 with kernel 4.18.0-372.26.1.0.1.el8\_6 or later. Required packages include core libraries, compiler runtimes, X11 components, RDMA and security-policy libraries, storage utilities, and system tools. Optional packages are available for IPMI, Database Client, RAC or Clusterware, and ACFS requirements.

Read More: \[Supported Red Hat Enterprise Linux 8 Distributions for x86-64\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/supported-red-hat-enterprise-linux-8-distributions-for-x86-64.html)

## Supported SUSE Linux Enterprise Server 15 Distributions for x86-64

SUSE Linux Enterprise Server 15 requires OpenSSH and SP5 with kernel 5.14.21-150500.53-default or later. Install the specified latest libraries, compiler components, X11 packages, capability and security-policy utilities, storage libraries, and system tools through SUSE repositories. ipmiutil and net-tools are optional for IPMI and RAC or Clusterware deployments.

Read More: \[Supported SUSE Linux Enterprise Server 15 Distributions for x86-64\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/supported-suse-linux-enterprise-server-15-distributions-for-x86-64.html)

## Installing Operating System Packages

Install the latest required packages from the operating system vendor’s enabled repositories using the appropriate package manager: DNF or YUM on Oracle Linux and Red Hat Enterprise Linux, or YaST on SUSE Linux Enterprise Server. For example, install the bc package with dnf install bc, yum install bc, or yast --install bc.
Read More: \[Installing Operating System Packages\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/operating-system-requirements-for-x86-64-linux-platforms/installing-operating-system-packages.html)


# Configuring Networks For Oracle Grid Infrastructure And Oracle Rac

## About Oracle Grid Infrastructure Network Configuration Options

Oracle Grid Infrastructure cluster installations require appropriate networking hardware, IP addresses, and open firewall ports. Each cluster needs at least a public interface for client and application access and a private interface for internode communication. All nodes must use the same IP protocol configuration, either IPv4 or IPv6, while redundant interface pairs must use matching protocols. VIPs can support IPv6 autoconfiguration, and current protocol and hardware support should be verified through Oracle certification resources.

Read More: [About Oracle Grid Infrastructure Network Configuration Options](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/about-oracle-grid-infrastructure-network-configuration-options.html)

## Understanding Network Addresses

During installation, classify each detected interface as public, private, or unused. Public interfaces support client access, public addresses, and VIPs; private interfaces provide the cluster interconnect and must connect every node on a dedicated, firewall-free subnet. VIPs must be unused, publicly accessible, and on the public subnet. SCAN provides cluster-wide, location-independent client access and should resolve through DNS or GNS, preferably to three addresses on the public subnet. Shared SCAN allows multiple clusters to reuse SCAN VIPs while separating cluster ports.

Read More: [Understanding Network Addresses](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/understanding-network-addresses.html)

## Network Interface Hardware Minimum Requirements

Each node requires at least one TCP/IP public NIC and one private interconnect NIC. Bonded, teamed, trunked, or aggregated networks are supported, and redundant private interfaces are recommended for availability and load balancing. Private interconnects require suitable UDP or RDS-capable networking, switches of at least 1 GbE, and preferably dedicated switches with MTU 9000 Jumbo Frames supported end to end. Token rings and crossover cables are unsupported; additional interfaces are recommended for third-party storage. On Oracle Linux RAC systems, reducing the loopback MTU can help prevent buffer-related failures.

Read More: [Network Interface Hardware Minimum Requirements](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/network-interface-hardware-minimum-requirements.html)

## Private Ip Interface Configuration Requirements

For a single private interface, every node must use an interface on the same subnet, with connectivity across the entire cluster; IPv4 and IPv6 are supported. With Redundant Interconnect Usage, multiple interfaces on distinct subnets provide HAIP addresses for load balancing and transparent failover. Every node must connect to every private subnet, and all interconnect endpoints must be reachable. Up to four interfaces are active during installation, while additional configured interfaces serve as reserves.

Read More: [Private Ip Interface Configuration Requirements](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/private-ip-interface-configuration-requirements.html)

## Ipv4 And Ipv6 Protocol Requirements

Oracle Grid Infrastructure and RAC support standard IPv4 and IPv6 configurations, including supported global and site-local IPv6 formats. Public interfaces may use IPv4, IPv6, or both after installation, but VIP and SCAN names must resolve consistently to one protocol during installation and cannot be mixed across nodes. Private interconnects may use either protocol, while redundant interface pairs must use the same protocol. GNS supports IPv4 DHCP and IPv6 stateless autoconfiguration, but unsupported legacy link-local and site-local IPv6 formats must not be used.

Read More: [Ipv4 And Ipv6 Protocol Requirements](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/ipv4-and-ipv6-protocol-requirements.html)

## Oracle Grid Infrastructure Ip Name And Address Requirements

Each node requires public and private interfaces, with all cluster host, VIP, and SCAN names resolvable by every configured DNS server. Addressing can use GNS with DHCP or IPv6 autoconfiguration, or static addresses managed through DNS and optionally hosts files. Static configurations require unused public, VIP, private, and preferably three DNS-based SCAN addresses, with public, VIP, and SCAN addresses sharing a subnet and private addresses isolated on another. Cluster names must be unique, alphanumeric or hyphenated, and no longer than 15 characters; SCAN should use DNS rather than hosts files for full functionality. Validate SCAN resolution with nslookup, and do not use NIS.

Read More: [Oracle Grid Infrastructure Ip Name And Address Requirements](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/oracle-grid-infrastructure-ip-name-and-address-requirements.html)

## Broadcast Requirements For Networks Used By Oracle Grid Infrastructure

ARP and UDP broadcasts must function across all public and private interfaces and any VLANs carrying them. ARP must be enabled for public and private RAC interfaces, and NOARP must not be configured. HAIP does not require public-network ARP, but VIP failover does.

Read More: [Broadcast Requirements For Networks Used By Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/broadcast-requirements-for-networks-used-by-oracle-grid-infrastructure.html)

## Multicast Requirements For Networks Used By Oracle Grid Infrastructure

Oracle mDNS uses multicast on cluster interfaces, so multicast must be enabled on the private interconnect across its broadcast domain. At minimum, support the 224.0.0.0/24 range and, where applicable, 230.0.1.0/24. Multicast is not required across routers.

Read More: [Multicast Requirements For Networks Used By Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/multicast-requirements-for-networks-used-by-oracle-grid-infrastructure.html)

## Domain Delegation To Grid Naming Service

When using GNS, configure DNS before installation to delegate resolution requests for the GNS-served subdomain to the cluster’s static GNS VIP. Choose a supported subdomain that is separate from, or exclusively reserved within, the corporate domain to prevent conflicts with other delegated names. The highly available GNS feature is deprecated in Oracle AI Database 26ai.

Read More: [Domain Delegation To Grid Naming Service](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/domain-delegation-to-grid-naming-service.html)

## Configuration Requirements For Oracle Flex Clusters

Oracle Flex Clusters provide scalable Grid Infrastructure deployments in which all nodes share coordinated policy management and direct access to shared storage. Flex ASM can run ASM instances on separate servers, use shared or dedicated private networks, and classify networks as PUBLIC, ASM & PRIVATE, PRIVATE, or ASM. Public addresses must share a subnet, and all addresses must be static or dynamically assigned through DHCP, IPv6 autoconfiguration, and GNS. VIPs may be assigned through DHCP and GNS or manually through DNS using RFC 952-compliant names and systematic naming patterns.

Read More: [Configuration Requirements For Oracle Flex Clusters](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/configuration-requirements-for-oracle-flex-clusters.html)

## Grid Naming Service Cluster Configuration Example

A GNS deployment requires a static GNS VIP and DNS delegation for the cluster subdomain. DHCP dynamically supplies node and SCAN addresses, which GNS registers and resolves, while IPv6 deployments can use autoconfiguration instead of DHCP. The example illustrates a two-node cluster with fixed public and GNS VIPs, dynamically assigned node VIPs and three SCAN VIPs, and private addresses on a separate subnet, all resolved through GNS where appropriate.

Read More: [Grid Naming Service Cluster Configuration Example](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/grid-naming-service-cluster-configuration-example.html)

## Manual Ip Address Configuration Example

Without GNS, configure public, VIP, private, and SCAN addresses before installation and verify gateway reachability. Public, VIP, and SCAN addresses must share a subnet, while private interfaces use a separate subnet and need not have resolvable names. VIP and SCAN addresses must initially be unused, SCAN should resolve through DNS to three addresses, and all names must comply with RFC 952. Hosts files may support node and VIP resolution, but DNS is preferred for SCAN functionality.

Read More: [Manual Ip Address Configuration Example](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/manual-ip-address-configuration-example.html)

## Network Interface Configuration Options

During installation, assign each NIC exactly one role: public, private, ASM, ASM & Private, or Do Not Use. Oracle Clusterware and RAC must use the same private adapters, with at least 1 GbE and 10 GbE recommended or InfiniBand for the interconnect. Ethernet-connected NAS requires a separate storage interface. Multiple private adapters enable Redundant Interconnect Usage for private-network availability, whereas public-interface redundancy requires bonding, teaming, or another third-party solution.

Read More: [Network Interface Configuration Options](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/network-interface-configuration-options.html)

## Multiple Private Interconnects And Oracle Linux

On Linux systems with multiple private interconnects, set each private NIC’s rp\_filter to 0 or 2 rather than strict mode 1, because strict filtering can discard valid interconnect packets. Public interfaces may retain strict filtering. Ensure the effective value of net.ipv4.conf.all.rp\_filter does not force strict filtering, since the kernel uses the maximum of the global and interface-specific settings. This guidance applies to Linux kernel 2.6.32 and later, including Exadata.

Read More: [Multiple Private Interconnects And Oracle Linux](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/multiple-private-interconnects-and-oracle-linux.html)

## Creating Scan Client Data File

To configure a shared SCAN for a client cluster, create a dedicated SCAN listener and ONS resource with srvctl, export both resources into a client data file, update the listener’s invited nodes, and start the listener. The operations require the grid user for listener tasks, root for ONS creation, and the client cluster name and output file as command parameters.
Read More: [Creating Scan Client Data File](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-networks-for-oracle-grid-infrastructure-and-oracle-rac/creating-scan-client-data-file.html)


# Configuring Users Groups and Environments for Oracle Grid Infrastructure and Oracle AI Database

## Creating Groups Users and Paths for Oracle Grid Infrastructure

Describes how to prepare Oracle Grid Infrastructure installation accounts, groups, inventory, and directories. It covers locating or creating the Oracle Inventory group, ensuring consistent user and group IDs across cluster nodes, selecting separate Grid and database owners, assigning required privilege groups, configuring non-symlink Oracle base and Grid home paths, and creating directories with appropriate ownership and permissions. It also emphasizes using a shared central inventory, separate Grid homes, local installation of cluster binaries, and avoiding Grid homes beneath Oracle base or owner home directories.

Read More: [Creating Groups Users and Paths for Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-ai-database/creating-groups-users-and-paths-for-oracle-grid-infrastructure.html)

## Oracle Installations with Standard and Job Role Separation Groups and Users

Explains standard and job-role-separated operating system authentication for Oracle Grid Infrastructure, ASM, and databases. It defines the Oracle Inventory, OSDBA, OSOPER, OSASM, OSDBA for ASM, OSBACKUPDBA, OSDGDBA, OSKMDBA, and OSRACDBA groups, describing their privileges and recommended separation by installation or database. It also covers the ASMSNMP monitoring account and distinguishes shared administrative configurations from role-specific users and groups designed to limit database and storage administration privileges.

Read More: [Oracle Installations with Standard and Job Role Separation Groups and Users](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-ai-database/oracle-installations-with-standard-and-job-role-separation-groups-and-users.html)

## Creating Operating System Privileges Groups

Provides commands and guidance for creating the operating system groups used by Oracle Grid Infrastructure, ASM, RAC, and database installations. It covers the OSASM, OSDBA for ASM, OSOPER for ASM, OSDBA, OSOPER, OSBACKUPDBA, OSDGDBA, OSKMDBA, and OSRACDBA groups, including their typical names, numeric IDs, and associated Oracle privileges such as SYSASM, SYSDBA, SYSOPER, SYSBACKUP, SYSDG, SYSKM, and SYSRAC.

Read More: [Creating Operating System Privileges Groups](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-ai-database/creating-operating-system-privileges-groups.html)

## Creating Operating System Oracle Installation User Accounts

Explains how to create and configure Oracle software owners such as `grid`, `oracle`, `oracle1`, and `oracle2`, ensuring the Oracle Inventory group is their primary group and assigning appropriate secondary privilege groups. It describes modifying existing accounts without changing their primary inventory group, identifying and synchronizing user and group IDs across cluster nodes, setting passwords, and configuring environments. It also provides minimal shared-privilege and fully role-separated examples with corresponding Oracle base and Grid home ownership and permissions.

Read More: [Creating Operating System Oracle Installation User Accounts](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-ai-database/creating-operating-system-oracle-installation-user-accounts.html)

## Configuring Software Owner User Environments

Details the environment preparation required for Oracle installation owners. It instructs administrators to set `umask 022`, configure resource limits, establish X display access, remove conflicting Oracle variables, set `DISPLAY` when installing remotely, and provide a private temporary directory with sufficient space when `/tmp` is inadequate. It also explains how to edit and reload shell startup files, verify settings, and unset variables such as `ORACLE_HOME`, `ORA_NLS10`, `TNS_ADMIN`, and `ORA_CRS_HOME` to prevent installation conflicts.

Read More: [Configuring Software Owner User Environments](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-ai-database/configuring-software-owner-user-environments.html)

## Enabling Intelligent Platform Management Interface Ipmi

Explains how IPMI supports Oracle Clusterware failure isolation and node fencing through BMC-managed hardware. It specifies requirements for compatible BMC firmware, IPMI utilities, management networking, and persistent drivers; provides Linux OpenIPMI module configuration and device verification steps; and describes configuring BMC networking, authentication, LAN access, and administrator accounts with `ipmitool`. Remote validation must be performed from another cluster node, using identical credentials and working IPMI connectivity on every node.

Read More: [Enabling Intelligent Platform Management Interface Ipmi](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-ai-database/enabling-intelligent-platform-management-interface-ipmi.html)

## Checking Resource Limits for Oracle Software Installation Users

Describes how to verify and configure resource limits for each Oracle installation owner. Recommended minimums include 1,024 soft and 65,536 hard open files, 2,047 soft and 16,384 hard processes, a 10,240 KB stack soft limit with a maximum hard limit of 32,768 KB, and locked memory equal to at least 90 percent of RAM with HugePages or 3 GB without HugePages. Limits can be checked with `ulimit` or `cluvfy`, adjusted in `/etc/security/limits.conf`, and activated by logging users out and back in.
Read More: [Checking Resource Limits for Oracle Software Installation Users](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-ai-database/checking-resource-limits-for-oracle-software-installation-users.html)


# Supported Storage Options For Oracle AI Database And Oracle Grid Infrastructure

## Supported Storage Options for Oracle Grid Infrastructure

Oracle Grid Infrastructure supports Oracle ASM, ACFS, NVMe-oF, local file systems, OCFS2, certified NFS/NAS, and direct-attached storage with different capabilities for Clusterware files, database binaries, data files, and recovery files. OCR and voting files require Oracle ASM or shared file systems, while raw or block devices used directly are unsupported; supported options may be combined when their individual requirements are met.

Read More: [Supported Storage Options for Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/supported-storage-options-for-oracle-ai-database-and-oracle-grid-infrastructure/supported-storage-options-for-oracle-grid-infrastructure.html)

## Oracle ACFS and Oracle ADVM

Oracle ACFS extends ASM with a general-purpose cluster and single-instance file system, while Oracle ADVM provides volume management and device-driver services through which ACFS accesses ASM. ACFS and ADVM support specified Oracle Linux, Red Hat Enterprise Linux, and SUSE Linux Enterprise Server kernels, but not Linux containers, and may require kernel patches and SELinux configuration. ACFS requires ASM, cannot store Clusterware files, has database encryption and replication restrictions, and has additional limitations in Oracle Restart configurations, including unsupported ACFS resources, registries, and data-file creation.

Read More: [Oracle ACFS and Oracle ADVM](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/supported-storage-options-for-oracle-ai-database-and-oracle-grid-infrastructure/oracle-acfs-and-oracle-advm.html)

## Storage Considerations for Oracle Grid Infrastructure and Oracle RAC

Oracle Clusterware OCR and voting files must use shared storage, such as ASM disk groups or a shared file system, because nodes lacking access to a majority of voting files restart. Oracle recommends separate ASM disk groups and failure groups for RAC database and recovery files, although supported storage options can be combined when requirements are satisfied. NFS may store database files with or without Direct NFS, and RAC deployments using ASM require Grid Infrastructure and ASM on all nodes with existing ASM instances stopped during configuration.

Read More: [Storage Considerations for Oracle Grid Infrastructure and Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/supported-storage-options-for-oracle-ai-database-and-oracle-grid-infrastructure/storage-considerations-for-oracle-grid-infrastructure-and-oracle-rac.html)

## Guidelines for Using Oracle ASM Disk Groups for Storage

During Grid Infrastructure installation, one or two ASM disk groups can be created, with the primary group holding OCR, voting files, and the ASM password file and a separate group recommended for OCR backups. Additional groups can be created later, and database, Clusterware, and recovery files may share or use separate groups depending on availability, performance, sizing, and manageability requirements. A single group is supported, but separating OCR backups and major file categories is generally preferable.

Read More: [Guidelines for Using Oracle ASM Disk Groups for Storage](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/supported-storage-options-for-oracle-ai-database-and-oracle-grid-infrastructure/guidelines-for-using-oracle-asm-disk-groups-for-storage.html)

## Guidelines for Configuring Oracle ASM Disk Groups on NFS

ASM disk groups can use NFS or block devices on supported NAS systems, provided mounts are available before installation and vendors certify the complete storage configuration. Direct NFS requires hard mounts, external redundancy is recommended, and dedicated Gigabit Ethernet or faster connections improve performance; ACFS and ADVM are incompatible with NFS-backed ASM disks. For quorum disks, SAN or iSCSI is preferred, while NFS deployments should use soft mounts for quorum storage and hard mounts for other ASM disks, with quorum failure groups enabling NFS use without hard mounts in appropriate extended-cluster designs.

Read More: [Guidelines for Configuring Oracle ASM Disk Groups on NFS](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/supported-storage-options-for-oracle-ai-database-and-oracle-grid-infrastructure/guidelines-for-configuring-oracle-asm-disk-groups-on-nfs.html)

## Using Logical Volume Managers with Oracle Grid Infrastructure and Oracle RAC

Oracle Grid Infrastructure and Oracle RAC support only cluster-aware volume managers. Third-party volume managers must be verified through Oracle certification resources to ensure that they are certified and suitable for RAC deployments.

Read More: [Using Logical Volume Managers with Oracle Grid Infrastructure and Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/supported-storage-options-for-oracle-ai-database-and-oracle-grid-infrastructure/using-logical-volume-managers-with-oracle-grid-infrastructure-and-oracle-rac.html)

## Using a Cluster File System for Oracle Clusterware Files

Since Oracle Grid Infrastructure 19c, OCR and voting files can be stored on Oracle ASM or a certified shared file system. OCFS2 is available for 64-bit Linux platforms, but Oracle does not recommend using it for Oracle Clusterware files.

Read More: [Using a Cluster File System for Oracle Clusterware Files](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/supported-storage-options-for-oracle-ai-database-and-oracle-grid-infrastructure/using-a-cluster-file-system-for-oracle-clusterware-files.html)

## About NFS Storage for Data Files

NAS systems expose shared storage through NFS, allowing supported database data files to serve both single-instance and RAC databases. Performance depends on network connectivity, so private dedicated Gigabit Ethernet or faster connections are recommended. NFS file systems must be correctly configured, mounted, and available on all required servers before installation.

Read More: [About NFS Storage for Data Files](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/supported-storage-options-for-oracle-ai-database-and-oracle-grid-infrastructure/about-nfs-storage-for-data-files.html)

## About Direct NFS Client Mounts to NFS Storage Devices

Direct NFS Client integrates NFS access into Oracle software to optimize I/O, supports NFSv3, NFSv4, NFSv4.1, and pNFS, and can use a dispatcher to improve scalability and connection efficiency. It requires suitable NFS write sizes and mounts visible to both the operating-system and Direct NFS clients, with fallback to kernel NFS if dNFS cannot connect. Mount definitions are searched in Oracle home, Oracle configuration, system, and mount-table locations; only one NFS client implementation may be active per instance, and NFSv4.2 requests are downgraded to NFSv4.1.

Read More: [About Direct NFS Client Mounts to NFS Storage Devices](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/supported-storage-options-for-oracle-ai-database-and-oracle-grid-infrastructure/about-direct-nfs-client-mounts-to-nfs-storage-devices.html)


# Configuring Storage for Oracle Grid Infrastructure

## Configuring Storage for Oracle Automatic Storage Management

Describes how to plan and configure Oracle ASM storage for Oracle Grid Infrastructure clusters, including database, recovery, OCR, and voting files. It covers redundancy options, failure groups, allocation units, metadata sizing, device-selection guidelines, NFS-based ASM files, existing disk-group validation, disk discovery strings, Clusterware storage requirements, and ASM upgrade behavior. ASMFD is desupported in Oracle AI Database 26ai and unsupported on newer Linux kernels, with ASMlib v3 recommended where applicable.

Read More: [Configuring Storage for Oracle Automatic Storage Management](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-storage-for-oracle-grid-infrastructure/configuring-storage-for-oracle-automatic-storage-management.html)

## Configuring Storage Device Path Persistence Using Oracle ASMLIB

Explains how Oracle ASMLIB provides persistent ASM disk labels and permissions, eliminates device rebinding after restarts, and requires the ASM discovery string ORCL:\* when used. It outlines installation considerations, including the requirement for ASMLib v3 on Oracle Linux 8 and later kernels, and provides procedures for safely stopping ASM and Clusterware, unloading ASMLIB, disabling its configuration, and removing its packages.

Read More: [Configuring Storage Device Path Persistence Using Oracle ASMLIB](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-storage-for-oracle-grid-infrastructure/configuring-storage-device-path-persistence-using-oracle-asmlib.html)

## Configuring NVMe Over Fabrics Storage Devices with Oracle ASM

Explains how Oracle ASM can use NVMe over Fabrics storage for database files through Oracle’s native user-space NVMe-oF solution on Linux. It defines supported kernel, networking, and target requirements; recommends dedicated high-speed connections; and provides procedures for configuring Linux TCP NVMe targets, namespaces, ports, and unique NQNs. It also describes building the NVMe ODM library, creating per-node nvmip.ora files, and discovering devices through the ASM disk string n:/_/_.

Read More: [Configuring NVMe Over Fabrics Storage Devices with Oracle ASM](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-storage-for-oracle-grid-infrastructure/configuring-nvme-over-fabrics-storage-devices-with-oracle-asm.html)

## Using Disk Groups with Oracle AI Database Files on Oracle ASM

Provides guidance for using existing or new ASM disk groups for Oracle Clusterware and database files, including custom failure-group design to protect against HBA failures. It recommends uniform device size and performance, separate physical devices, and avoidance of unnecessary logical-volume layers. It also explains how to place database and recovery files on conventional file systems, check available capacity, create directories with appropriate ownership and permissions, and keep the recovery area on separate physical storage when possible.

Read More: [Using Disk Groups with Oracle AI Database Files on Oracle ASM](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-storage-for-oracle-grid-infrastructure/using-disk-groups-with-oracle-ai-database-files-on-oracle-asm.html)

## Deploying Oracle Direct NFS for Oracle AI Database

Describes configuring Oracle Direct NFS for file-system-based database storage, including recommended separation of software and data disks, NFS rsize and wsize settings of at least 32768, TCP buffer tuning, and network restart procedures. It details the oranfstab configuration attributes for servers, local and remote paths, exports, mounts, timeouts, NFS versions, routing, SNMP management, and security modes ranging from UNIX authentication to Kerberos integrity and privacy, with examples for multipath, multiple exports, and authenticated mounts.

Read More: [Deploying Oracle Direct NFS for Oracle AI Database](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-storage-for-oracle-grid-infrastructure/deploying-oracle-direct-nfs-for-oracle-ai-database.html)

## Enabling and Disabling Direct NFS Client Control of NFS

Explains how to enable Direct NFS Client control by running the dnfs\_on build command from the Grid home on every cluster node, including shared-home environments. It notes that Direct NFS is enabled by default and that restarting a database is required after removing an NFS path in use. The page also lists prerequisites for Hybrid Columnar Compression through Direct NFS, including SNMP on the ZFS server, optional management and community settings in oranfstab, and availability of the Net-SNMP library.

Read More: [Enabling and Disabling Direct NFS Client Control of NFS](https://orahub.oci.oraclecorp.com/db-ua-dev/text-editor-poc/-/tree/no-doc-repo/configuring_storage_for_oracle_grid_infrastructure/26ai/enabling_and_disabling_direct_nfs_client_control_of_nfs.md?ref_type=heads)

## Creating Oracle ASM Client Data File

Describes generating an Oracle ASM client data file on the storage-server cluster with the ASMCMD mkcc command and copying it to a secure location on the client cluster node. ACLs must be enabled beforehand, the grid user must retain access, and credentials should not be exposed to other users. The client cluster version can be specified when it differs from the storage-server version.

Read More: [Creating Oracle ASM Client Data File](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-storage-for-oracle-grid-infrastructure/creating-oracle-asm-client-data-file.html)

## Configuring Oracle Advanced Cluster File System

Provides the procedure for creating an Oracle ACFS file system for an Oracle RAC database home using ASMCA after installing Grid Infrastructure. Administrators verify mount-point permissions, select an ASM data disk group, define a unique volume name, mount point, size, database-home owner, and OSDBA group, then either allow ASMCA to run privileged configuration commands or execute its generated script as root. The resulting mount point must be selected as the Oracle RAC home during database installation.

Read More: [Configuring Oracle Advanced Cluster File System](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-storage-for-oracle-grid-infrastructure/configuring-oracle-advanced-cluster-file-system.html)

## Checking OCFS2 Version Manually

Explains how to verify installed OCFS2 component versions using modinfo and RPM queries. The console and tools packages must be version 1.2.7 or later, associated kernel components must meet the corresponding version pattern, and shared Oracle RAC homes require OCFS2 version 1.4.1 or later.
Read More: [Checking OCFS2 Version Manually](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/configuring-storage-for-oracle-grid-infrastructure/checking-ocfs2-version-manually.html)


# Installing Oracle Grid Infrastructure

Review this information for installation and deployment options for Oracle Grid Infrastructure.

Oracle AI Database and Oracle Grid Infrastructure installation software is available in multiple media, and can be installed using several options. The Oracle Grid Infrastructure software is available as an image, available for download from the Oracle Technology Network website, or the Oracle Software Delivery Cloud portal. In most cases, you use the graphical user interface (GUI) provided by Oracle Universal Installer to install the software. You can also use Oracle Universal Installer to complete silent mode installations, without using the GUI. You can also use Oracle Fleet Patching and Provisioning for subsequent Oracle Grid Infrastructure and Oracle AI Database deployments.

## About Image-Based Oracle Grid Infrastructure Installation

Image-based installation simplifies Oracle Grid Infrastructure deployment by extracting the software image into a properly permissioned Grid home and running `gridSetup.sh`. It supports new clusters, Oracle Restart, upgrades, software-only installations, node additions or removals, silent automation, customized patched images, and subsequent deployment through Oracle Fleet Patching and Provisioning.

Read More: [About Image-Based Oracle Grid Infrastructure Installation](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/about-image-based-oracle-grid-infrastructure-installation.html)

## Setup Wizard Installation Options for Creating Images

The `runInstaller` and `gridSetup.sh` setup wizards can create reusable gold images with `-createGoldImage`, specify the output location with `-destinationLocation`, exclude selected files with `-exclFiles`, and display usage information with `-help`. Gold images are generated as compressed archives in the designated destination.

Read More: [Setup Wizard Installation Options for Creating Images](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/setup-wizard-installation-options-for-creating-images.html)

## Downloading Oracle Software

Oracle AI Database software can be downloaded from the Oracle database software website or Oracle Software Delivery Cloud, subject to applicable licensing. Download procedures require selecting the correct product and platform, allocating sufficient space for archives and extraction, organizing files by product, verifying file sizes and checksums, and extracting the archives into the intended directories.

Read More: [Downloading Oracle Software](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/downloading-oracle-software.html)

## Understanding Cluster Configuration Options

Oracle Grid Infrastructure supports clusters for Oracle RAC databases, generic applications, and extended multi-site deployments. RAC clusters provide local Grid Infrastructure, Oracle ASM, shared storage, and support for up to 64 nodes, while generic-application clusters provide high availability and rolling maintenance with minimal network and storage requirements. Extended clusters distribute nodes and storage across sites with defined ASM failure-group and quorum configurations; Domain Services Clusters are desupported in Oracle AI Database 26ai, and QoS Management is also desupported.

Read More: [Understanding Cluster Configuration Options](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/understanding-cluster-configuration-options.html)

## Installing Oracle Grid Infrastructure for a New Cluster

This page introduces installation procedures for new Oracle Grid Infrastructure clusters managing RAC databases or generic applications. Installation uses an extracted image and the `gridSetup.sh` wizard, requires prepared network, storage, operating-system users and groups, and root-script access, and uses SSH to distribute software from the first node. ASM Filter Driver is desupported in Oracle AI Database 26ai, with ASMlib v3 recommended for applicable Linux environments.

Read More: [Installing Oracle Grid Infrastructure for a New Cluster](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/installing-oracle-grid-infrastructure-for-a-new-cluster.html)

## Installing Oracle Grid Infrastructure to Manage Oracle RAC Databases

The GUI procedure installs Grid Infrastructure for RAC by extracting a gold image, configuring cluster and SCAN information, adding nodes and SSH connectivity, assigning network interfaces, selecting ASM or shared-file storage, creating disk groups, setting ASM credentials and management options, defining installation and inventory locations, running prerequisite checks, and executing root scripts. It also supports extended clusters, ASM client storage, OCR backups, automatic fixups, and automated or manual root-script execution; after completion, Clusterware and ASM should be validated without deleting Oracle temporary directories.

Read More: [Installing Oracle Grid Infrastructure to Manage Oracle RAC Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/installing-oracle-grid-infrastructure-to-manage-oracle-rac-databases.html)

## Installing Oracle Grid Infrastructure to Manage Generic Applications

The GUI procedure configures Grid Infrastructure for generic applications or single-server rolling database maintenance. It uses a Grid image, defines the cluster and nodes, establishes SSH, assigns one interface for public, private, and ASM traffic, configures ASM or shared-file storage and optional OCR backups, completes security and management settings, validates prerequisites, and runs root scripts. Virtual hostnames and separate interfaces are unnecessary, and the resulting cluster can host databases or other highly available applications.

Read More: [Installing Oracle Grid Infrastructure to Manage Generic Applications](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/installing-oracle-grid-infrastructure-to-manage-generic-applications.html)

## Installing Oracle Grid Infrastructure Using Command-Line Interface

Oracle Grid Infrastructure 26ai supports command-line installation through silent `gridSetup.sh` execution. The process extracts the image, supplies cluster identity, nodes, SCAN, network interfaces, usage, storage, disk groups, redundancy, Oracle base, inventory, management, automatic-fixup, and root-script parameters, then prompts for the root password to complete configuration.

Read More: [Installing Oracle Grid Infrastructure Using Command-Line Interface](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/installing-oracle-grid-infrastructure-using-command-line-interface.html)

## Installing Oracle Grid Infrastructure Using a Cluster Configuration File

A cluster configuration file provides node public hostnames, optional virtual hostnames, and optional site assignments for extended clusters, allowing installation details to be prepared in advance. The file can use space- or colon-separated values, omit VIPs for software-only installations, specify `AUTO` for dynamically assigned VIPs, and be based on the sample file supplied under the Grid home installation directory.

Read More: [Installing Oracle Grid Infrastructure Using a Cluster Configuration File](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/installing-oracle-grid-infrastructure-using-a-cluster-configuration-file.html)

## Installing Only the Oracle Grid Infrastructure Software

Software-only installation deploys Grid Infrastructure binaries to selected nodes but requires later configuration of Oracle Clusterware and ASM. The workflow extracts the image, selects Set Up Software Only, runs required inventory and root scripts, completes prerequisite validation with `runcluvfy.sh`, and then configures the cluster through the GUI or response files. Network monitoring can additionally be configured with `oracle_install_crs_Ping_Targets` so external hosts determine public-network availability.

Read More: [Installing Only the Oracle Grid Infrastructure Software](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/installing-only-the-oracle-grid-infrastructure-software.html)

## About Deploying Oracle Grid Infrastructure Using Oracle FPP

Oracle Fleet Patching and Provisioning provides centralized or client-based lifecycle management for Grid Infrastructure, Oracle Restart, Oracle AI Database, and other software homes from release 12.2 onward. It uses standardized gold images to automate provisioning, patching, upgrades, scaling, and cluster creation, while supporting out-of-place deployment, validation and dry runs, resumable operations, reduced downtime, rolling maintenance, zero-downtime upgrades, and environment-specific workflow customizations.

Read More: [About Deploying Oracle Grid Infrastructure Using Oracle FPP](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/about-deploying-oracle-grid-infrastructure-using-oracle-fpp.html)

## Confirming Oracle Clusterware Function

After installation, log in as root and run `crsctl check cluster -all` to verify that Cluster Ready Services, Cluster Synchronization Services, and the Event Manager are online on every node. Oracle temporary directories under `/tmp` and `/var/tmp` must not be manually deleted or cleaned by scheduled jobs while Clusterware is running, because doing so can cause delays and CRS-0184 errors.

Read More: [Confirming Oracle Clusterware Function](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/confirming-oracle-clusterware-function.html)

## Confirming Oracle ASM Function for Oracle Clusterware Files

Use `srvctl status asm` as the Grid Infrastructure installation owner to verify that Oracle ASM is running on the cluster nodes and supporting Clusterware files. ASM and Oracle Net resources must be managed with the `srvctl` executable from the Grid home rather than a database home.

Read More: [Confirming Oracle ASM Function for Oracle Clusterware Files](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/confirming-oracle-asm-function-for-oracle-clusterware-files.html)

## Understanding Offline Processes in Oracle Grid Infrastructure

Some Grid Infrastructure resources appear offline immediately after installation because they are preconfigured for optional products but are not yet enabled. Resources with both target and actual state offline are registered but inactive, consume no system resources, and generally require no action unless a subsequently installed Oracle product needs them activated; their status can be inspected with `crsctl status resource`.

Read More: [Understanding Offline Processes in Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/understanding-offline-processes-in-oracle-grid-infrastructure.html)

## Enabling FIPS 140.3 for Oracle Grid Infrastructure

FIPS 140.3 requires its support fixes to be installed on every cluster node before activation and should normally be enabled consistently across the cluster. With FIPS enabled, GPnP profiles use RSA-SHA512 signatures; without it, they use RSA-SHA1. After confirming supported patch levels, enable FIPS in a rolling sequence by stopping Grid Infrastructure on each node, applying the platform-specific configuration, restarting the stack, verifying GPnP and cluster operation, and proceeding to the next node.

Read More: [Enabling FIPS 140.3 for Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/installing-oracle-grid-infrastructure/enabling-fips-140.3-for-oracle-grid-infrastructure.html)


# Patching Oracle Grid Infrastructure

You can download and install Oracle Grid Infrastructure patches either as a complete gold image with pre-applied RUs or as individual software patches from My Oracle Support.

## About Individual Oracle Grid Infrastructure Patches

Oracle ASM individual patches, also called one-off patches, are release-specific patches that can be downloaded and applied to Oracle Grid Infrastructure with the setup.exe -applyOneOffs command. Oracle Clusterware inventory records installed patches and reports conflicts with patches being applied. OPatch and OPatchAuto remain deprecated for out-of-place patching.

Read More: [About Individual Oracle Grid Infrastructure Patches](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/patching-oracle-grid-infrastructure/about-individual-oracle-grid-infrastructure-patches.html)

## About Oracle Grid Infrastructure Software Patch Levels

An Oracle Grid Infrastructure software patch level comprises all applied one-off patches and Release Updates for the Grid Infrastructure release, including Oracle ASM. The release identifies the major version and RU level; one-off patches do not change the RU number. All cluster nodes must use the same release and patch level during normal operation, although one-off patches can be applied using rolling upgrades because patch levels within a release remain mutually compatible.

Read More: [About Oracle Grid Infrastructure Software Patch Levels](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/patching-oracle-grid-infrastructure/about-oracle-grid-infrastructure-software-patch-levels.html)

## About Zero-Downtime Oracle Grid Infrastructure Patching

Zero-downtime patching keeps supported Oracle RAC or Oracle RAC One Node database instances and client connections active during out-of-place Grid Infrastructure patching, while ACFS remains mounted and database-home listeners remain available; Grid-home listeners restart. It applies to Grid Infrastructure 19c RU 19.8 and later with database releases 19c or later, subject to adequate system resources. Operating system drivers are copied but not activated automatically, so driver updates require a kernel restart or rootcrs.sh -updateosfiles followed by node restarts; patches containing driver updates require -skipDriverUpdate.

Read More: [About Zero-Downtime Oracle Grid Infrastructure Patching](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/patching-oracle-grid-infrastructure/about-zero-downtime-oracle-grid-infrastructure-patching.html)

## Applying Patches To Oracle Grid Infrastructure

Oracle Grid Infrastructure patches can be applied through zero-downtime out-of-place switching, during installation or upgrade with -applyRU and -applyOneOffs, after installation using rolling OPatchAuto procedures, or when Clusterware cannot start by stopping and unlocking the home, applying OPatch, updating OLR and OCR, and managing rolling-patch mode. Zero-downtime workflows require a new registered Grid home and use switchGridHome, followed by verification and, if necessary, rollback. Oracle recommends Oracle FPP Local Mode for out-of-place patching, while OPatch and OPatchAuto remain available for in-place patching.

Read More: [Applying Patches To Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/patching-oracle-grid-infrastructure/applying-patches-to-oracle-grid-infrastructure.html)

## Patching And Switching Oracle Grid Infrastructure Homes

The switchGridHome command switches a cluster between Grid Infrastructure homes for different Release Updates within the same release and can apply one-off patches. The process creates and registers a distinct new home, installs the current OPatch version, switches homes in silent or interactive mode, and optionally enables zero-downtime patching or skips ACFS driver updates. A failed switch can be rolled back, and a successful deployment can be reversed by unlocking and switching back to the former home.

Read More: [Patching And Switching Oracle Grid Infrastructure Homes](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/patching-oracle-grid-infrastructure/patching-and-switching-oracle-grid-infrastructure-homes.html)

## Patching Oracle Grid Infrastructure Using Oracle Fpp Local Mode

Oracle FPP Local Mode patches Grid Infrastructure by deploying a new home with rhpctl deploy home and moving the cluster from the old home to the new one with rhpctl move gihome. The move command is issued from only one node and automatically completes across the remaining nodes; if it fails, it must be rerun from the same initiating node.

Read More: [Patching Oracle Grid Infrastructure Using Oracle Fpp Local Mode](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/patching-oracle-grid-infrastructure/patching-oracle-grid-infrastructure-using-oracle-fpp-local-mode.html)

## Using Oracle Update Advisor In Oracle Fpp Local Mode

Oracle Update Advisor in FPP Local Mode evaluates an Oracle home, identifies its patch health and recommended target version, generates a patched gold image, and makes it available for download. The workflow registers an advisor user, runs rhpctl evaluate patch, checks the asynchronous request with rhpctl query patch, downloads the image using rhpctl download image, and then applies it through the standard FPP Local Mode procedure. With Oracle Restart, this method supports patching the database home but not the Grid Infrastructure home.

Read More: [Using Oracle Update Advisor In Oracle Fpp Local Mode](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/patching-oracle-grid-infrastructure/using-oracle-update-advisor-in-oracle-fpp-local-mode.html)

## Changing The Oracle Grid Infrastructure Base Path

For Oracle Grid Infrastructure 19c RU 19.21 and later, the base directory can be relocated by stopping Clusterware, TFA, and dependent applications, copying the base, updating ownership and configuration references across all nodes, changing OLR and related Grid Infrastructure paths, restoring permissions with rootcrs.sh -init, moving AHF data with ahfctl movedatadir, and restarting Clusterware. The old base should be retained temporarily as a backup, and all executables and applications using the old location must be stopped before the change.
Read More: [Changing The Oracle Grid Infrastructure Base Path](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/patching-oracle-grid-infrastructure/changing-the-oracle-grid-infrastructure-base-path.html)


# Upgrading Oracle Grid Infrastructure

Oracle Grid Infrastructure upgrade consists of upgrade of Oracle Clusterware and Oracle Automatic Storage Management (Oracle ASM).

Oracle Grid Infrastructure upgrades can be rolling upgrades, in which a subset of nodes are brought down and upgraded while other nodes remain active.

## Understanding Out-Of-Place Upgrade

An out-of-place upgrade installs the newer Oracle Clusterware release in a separate Grid home, allowing rolling upgrades with both software versions present while only one is active. Upgrades may be performed across all nodes or progressively across selected nodes, but in-place Oracle Grid Infrastructure upgrades are unsupported.

Read More: [Understanding Out-Of-Place Upgrade](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/understanding-out-of-place-upgrade.html)

## About Oracle Grid Infrastructure Upgrade and Downgrade

Oracle Grid Infrastructure supports rolling upgrades, which preserve service on other nodes, and non-rolling upgrades, which require a cluster outage while the old stack is replaced. All upgrades use a new Grid home, and supported downgrades restore an earlier release with its configuration and feature limitations. ASM upgrades can be performed with ASMCA, and cluster backups cannot be used until the upgrade is complete.

Read More: [About Oracle Grid Infrastructure Upgrade and Downgrade](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/about-oracle-grid-infrastructure-upgrade-and-downgrade.html)

## Options for Oracle Grid Infrastructure Upgrades

Oracle Grid Infrastructure 26ai supports upgrades from releases 19c and 21c. Administrators can choose a rolling upgrade that processes nodes individually while maintaining availability on other nodes or a non-rolling upgrade that stops the cluster and upgrades all nodes together.

Read More: [Options for Oracle Grid Infrastructure Upgrades](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/options-for-oracle-grid-infrastructure-upgrades.html)

## Restrictions for Oracle Grid Infrastructure Upgrades

Oracle Grid Infrastructure upgrades are always out-of-place and must use the owner of the existing installation. Before upgrading to 26ai, migrate ASM Filter Driver to ASMLib, remove any GIMR, verify required patches and prerequisites with CVU, and ensure OCR and voting files are stored on supported storage rather than raw or block devices. The new Grid home is not fully usable until the upgrade finishes, existing Grid home files must not be deleted, and database management commands should continue to use the appropriate earlier homes during the transition. Shared homes, single-instance ASM configurations, and storage layouts require additional handling as described by their respective restrictions.

Read More: [Restrictions for Oracle Grid Infrastructure Upgrades](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/restrictions-for-oracle-grid-infrastructure-upgrades.html)

## Preparing to Upgrade an Existing Oracle Clusterware Installation

Existing Oracle Clusterware installations must be upgraded out-of-place, with preparation covering compatibility review, patching, installation ownership, operating-system support, storage migration, ASM password-file placement, CVU and dry-run validation, database shutdown, environment cleanup, software backups, and HugePages sizing. Administrators must remove ASMFD and GIMR where applicable, ensure OCR integrity, migrate unsupported storage configurations, and run ORAchk for upgrade readiness. Required environment variables and PATH entries must be cleared, and any GIMR or NFS-based Clusterware files must be removed or migrated before proceeding.

Read More: [Preparing to Upgrade an Existing Oracle Clusterware Installation](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/preparing-to-upgrade-an-existing-oracle-clusterware-installation.html)

## Understanding Rolling Upgrades Using Batches

Rolling upgrades can be organized into up to three node batches using root-user automation, allowing services to be relocated between batches so availability is preserved. Oracle recommends automated root scripts that stop and restart instances as needed, although manual execution remains supported. The local installer node must be in the first batch, and adding nodes during a rolling upgrade is unsupported.

Read More: [Understanding Rolling Upgrades Using Batches](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/understanding-rolling-upgrades-using-batches.html)

## Performing Rolling Upgrade of Oracle Grid Infrastructure

A rolling Oracle Grid Infrastructure upgrade can be performed through the setup wizard or command line after extracting the new image, migrating ASMFD to ASMLib, removing GIMR, and preparing FPP metadata when necessary. The installer selects nodes, executes root upgrade scripts automatically or manually, and installs the new home across the cluster; unreachable nodes may be skipped or later handled with forced upgrade procedures. Afterward, update scripts, applications, Enterprise Manager parameters, OCR backup locations, and related configuration to reference the new Grid home.

Read More: [Performing Rolling Upgrade of Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/performing-rolling-upgrade-of-oracle-grid-infrastructure.html)

## About Upgrading Oracle Grid Infrastructure Using Oracle FPP

Oracle Fleet Patching and Provisioning provides centralized lifecycle management for Grid Infrastructure, database, Restart, middleware, and application homes through standardized gold images. It supports provisioning, patching, upgrades, cluster expansion, rollback, and reduced downtime across supported releases, while improving automation, consistency, change control, and reuse of software homes.

Read More: [About Upgrading Oracle Grid Infrastructure Using Oracle FPP](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/about-upgrading-oracle-grid-infrastructure-using-oracle-fpp.html)

## Updating Oracle Enterprise Manager Cloud Control Target Parameters

After an out-of-place Grid Infrastructure upgrade, Enterprise Manager Cloud Control must be updated to use the new Grid home because stale CRS\_HOME values can break cluster monitoring. Administrators should update the cluster target’s Oracle Home, change CRS\_HOME in each agent’s emctl script, and rediscover or reconfigure new ASM listener and other Clusterware resource targets with the required host and monitoring credentials.

Read More: [Updating Oracle Enterprise Manager Cloud Control Target Parameters](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/updating-oracle-enterprise-manager-cloud-control-target-parameters.html)

## Unlocking and Deinstalling the Previous Release Grid Home

Before removing the previous Grid home, root must restore appropriate permissions and ownership, after which the installation owner should run the old release deinstall utility in check-only and deinstallation modes. The generated rootdeinstall script must then be executed as root, using the deinstall utility from the same software release as the home being removed.

Read More: [Unlocking and Deinstalling the Previous Release Grid Home](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/unlocking-and-deinstalling-the-previous-release-grid-home.html)

## Checking Cluster Health Monitor Repository Size After Upgrading

When upgrading from IPD/OS, review the Cluster Health Monitor repository because the former repository is deleted and the default retention is at least 1 GB or one hour. Retention can be increased with oclumon, within the one-hour-to-three-day limit, provided sufficient local or shared storage is available on every cluster node.

Read More: [Checking Cluster Health Monitor Repository Size After Upgrading](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/checking-cluster-health-monitor-repository-size-after-upgrading.html)

## Downgrading Oracle Clusterware to an Earlier Release

Oracle Clusterware can be downgraded after successful or failed upgrades, but only to the release from which the upgrade originated, and post-upgrade configuration changes are lost. Downgrades require special handling for FIPS 140.3, may affect newer RAC databases, and generally run downgrade scripts on all but one node before processing the final node and restoring the earlier Grid home. Failed upgrades can use silent or online downgrade procedures depending on the point of failure.

Read More: [Downgrading Oracle Clusterware to an Earlier Release](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/downgrading-oracle-clusterware-to-an-earlier-release.html)

## Completing Failed or Interrupted Installations and Upgrades

Failed or interrupted installations and upgrades require manual completion of root scripts, configuration assistants, inventory updates, or node membership changes. Failed nodes may be deinstalled, removed from Clusterware, and added again through the installer; first-node failures require correction or reboot followed by rerunning root scripts and configuration tools, while remote-node failures require retrying automation or executing the appropriate root scripts directly.

Read More: [Completing Failed or Interrupted Installations and Upgrades](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/completing-failed-or-interrupted-installations-and-upgrades.html)

## Patching, Upgrading, and Downgrading Oracle Grid Infrastructure with FIPS 140.3

FIPS 140.3 support fixes must be installed on every cluster node before FIPS is enabled anywhere. Rollback to an older unsupported release is prohibited when FIPS is enabled and the GPnP profile uses RSA-SHA512; administrators must first disable FIPS across all nodes, update and verify the GPnP profile is re-signed with RSA-SHA1, and only then perform the rollback.

Read More: [Patching, Upgrading, and Downgrading Oracle Grid Infrastructure with FIPS 140.3](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/upgrading-oracle-grid-infrastructure/patching-upgrading-and-downgrading-oracle-grid-infrastructure-with-fips-140.3.html)


# Oracle Grid Infrastructure Postinstallation Tasks

Complete configuration tasks after you install Oracle Grid Infrastructure.

You are required to complete some configuration tasks after Oracle Grid Infrastructure is installed. In addition, Oracle recommends that you complete additional tasks immediately after installation. You must also complete product-specific configuration tasks before you use those products.

> **Note:**
>
> This chapter describes basic configuration only. Refer to product-specific administration and tuning guides for more detailed configuration and tuning information.

## Downloading Release Update Patches

After installation, download and install the latest Oracle Release Updates or Monthly Recommended Patches through My Oracle Support. Search for patches by name, number, bug, product, release, platform, or language; download the patch, review its README, and follow the application instructions. For Oracle AI Database 26ai, Oracle recommends out-of-place RU patching with Gold images; OPatch and OPatchAuto remain available for in-place patching, while the Free release does not support RUs.

Read More: [Downloading Release Update Patches](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-postinstallation-tasks/downloading-release-update-patches.html)

## About Installing Oracle Autonomous Health Framework

Oracle Autonomous Health Framework is preinstalled with Oracle AI Database and provides proactive health checks and diagnostic collection across the Oracle software stack. Oracle recommends updating it through the latest Database Release Update or by obtaining the current version from My Oracle Support. It incorporates Oracle ORAchk, Oracle EXAchk, and Trace File Analyzer capabilities and checks environments including databases, Grid Infrastructure, RAC, GoldenGate, Exadata, SuperCluster, Recovery Appliance, and upgrade or MAA readiness.

Read More: [About Installing Oracle Autonomous Health Framework](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-postinstallation-tasks/about-installing-oracle-autonomous-health-framework.html)

## Creating a Fast Recovery Area

Create a fast recovery area for standalone or RAC databases when configuring storage, preferably in a separate disk group to reduce contention. Configure its location with DB\_RECOVERY\_FILE\_DEST and its capacity with DB\_RECOVERY\_FILE\_DEST\_SIZE; RMAN then manages backups, archived logs, control file backups, and database copies stored there. Size the area to retain at least several days of recovery data and, ideally, the files required by the backup retention policy. Use ASM Configuration Assistant to create a dedicated disk group, selecting an appropriate name, redundancy level, and eligible member disks.

Read More: [Creating a Fast Recovery Area](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-postinstallation-tasks/creating-a-fast-recovery-area.html)

## Checking the SCAN Configuration

The Single Client Access Name provides location-independent client access to the cluster and allows nodes to be added or removed without reconfiguring clients. Verify that DNS or the configured naming service correctly resolves the SCAN addresses by running cluvfy comp scan from the Grid home bin directory. After installation, SCAN listeners redirect client requests to appropriate cluster servers.

Read More: [Checking the SCAN Configuration](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-postinstallation-tasks/checking-the-scan-configuration.html)

## Setting Resource Limits for Oracle Clusterware and Associated Databases and Applications

After installing Oracle Grid Infrastructure, configure resource limits for Oracle Clusterware processes and databases or applications managed by it in Grid\_home/crs/install/s\_crsconfig\_nodename\_env.txt. Parameters such as CRS\_LIMIT\_NPROC control limits including the maximum number of processes; modify the file only as documented or under Oracle Support guidance.

Read More: [Setting Resource Limits for Oracle Clusterware and Associated Databases and Applications](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-postinstallation-tasks/setting-resource-limits-for-oracle-clusterware-and-associated-databases-and-applications.html)

## About Changes in Default SGA Permissions for Oracle AI Database

Oracle AI Database restricts read and write access to the System Global Area by default to the Oracle installation owner, improving security but potentially limiting administration by OSDBA members. The ALLOW\_GROUP\_ACCESS\_TO\_SGA initialization parameter defaults to FALSE on Linux and UNIX platforms; set it to TRUE only when OSDBA members require SGA read access. Oracle strongly recommends retaining the default restricted permissions.

Read More: [About Changes in Default SGA Permissions for Oracle AI Database](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-postinstallation-tasks/about-changes-in-default-sga-permissions-for-oracle-ai-database.html)

## Using Earlier Oracle AI Database Releases with Oracle Grid Infrastructure

Oracle Grid Infrastructure 26ai supports Oracle Database 19c, 21c, and Oracle AI Database 26ai, but earlier databases must be administered with tools from their own Oracle homes rather than 26ai Grid home utilities such as srvctl and lsnrctl. Earlier database homes may reside on Oracle ACFS, and ASM disk groups must be administered with ASMCA instead of DBCA. To administer 26ai local and SCAN listeners, use lsnrctl from the 26ai Grid home, not earlier Oracle homes.

Read More: [Using Earlier Oracle AI Database Releases with Oracle Grid Infrastructure](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-postinstallation-tasks/using-earlier-oracle-ai-database-releases-with-oracle-grid-infrastructure.html)

## Relinking Oracle Grid Infrastructure for a Cluster Binaries

On Oracle Linux 8 and earlier, relink modified Oracle Grid Infrastructure binaries after installation, ensuring all Grid-home executables, dependent applications, and any ACFS file systems are stopped or unmounted first. As root, unlock the Grid home with rootcrs.sh, as grid run the Grid-home relink command, and as root execute rootadd\_rdbms.sh and relock the home with rootcrs.sh. Relinking is required after applicable operating system patches or upgrades; it is generally unnecessary for fresh installations, upgrades, or patches on Oracle Linux 9 and later.

Read More: [Relinking Oracle Grid Infrastructure for a Cluster Binaries](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-postinstallation-tasks/relinking-oracle-grid-infrastructure-for-a-cluster-binaries.html)


# Removing Oracle AI Database Software

## About Oracle Deinstallation Options

The `deinstall` utility, located in each Oracle home, removes supported Oracle AI Database, Grid Infrastructure, RAC, and Client installations, but not individual components. It can generate or consume response files, must be run from the same software release, and may require complete configuration details for failed or inactive installations. Grid Infrastructure removal additionally requires root scripts, ACFS dismounting, ADVM disabling, and GNS DNS cleanup when applicable. If no other homes remain in the central inventory, deinstallation may delete Oracle base administration, diagnostic, recovery, and data directories, including user-owned data and configuration files outside the Oracle base, so Oracle recommends OFA layouts and exclusive Oracle paths.

Read More: [About Oracle Deinstallation Options](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/removing-oracle-ai-database-software/about-oracle-deinstallation-options.html)

## Oracle Deinstallation Deinstall

The `deinstall` command stops and removes Oracle software and configuration for a specific Oracle home. Its options support interactive or silent execution, configuration inspection with `-checkonly`, response-file selection and overrides, custom response, temporary, and log directories, local-only cluster deinstallation, preservation of local or remote Grid homes, and help. Silent mode requires accessible configuration data or a suitable response file, while `-checkonly` creates a response file without removing software.

Read More: [Oracle Deinstallation Deinstall](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/removing-oracle-ai-database-software/oracle-deinstallation-deinstall.html)

## Removing the Oracle Grid Infrastructure Home

To remove a previous-release Grid Infrastructure home after removing the current installation, first use root privileges to correct the old home’s permissions and ownership. As the Grid owner, run the old home’s `deinstall` utility with `-checkonly`, then perform the silent deinstallation and, as root, execute the generated `rootdeinstall.sh` script. The deinstallation utility must match the release of the home being removed and must not come from a later release.

Read More: [Removing the Oracle Grid Infrastructure Home](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/removing-oracle-ai-database-software/removing-the-oracle-grid-infrastructure-home.html)

## Deinstallation Examples for Oracle AI Database

Run `deinstall` from the Oracle home’s `deinstall` directory to start interactively, or use `-checkonly` to discover configuration details and generate a response file. The resulting file can be supplied with `-paramfile` to remove an Oracle Database or Grid Infrastructure home noninteractively; the examples show response-file usage for both database and Grid homes.

Read More: [Deinstallation Examples for Oracle AI Database](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/removing-oracle-ai-database-software/deinstallation-examples-for-oracle-ai-database.html)

## Deinstallation Response File Example for Oracle Grid Infrastructure for a Cluster

A Grid Infrastructure cluster response file defines the home, inventory and base paths, cluster nodes, local and remote nodes, ASM disk groups and discovery settings, network interfaces, VIPs, SCAN, storage configuration, ownership, logging, and silent-operation parameters. The example represents a two-node cluster and illustrates the values required by `deinstall -paramfile`; quotation marks should generally be omitted, except for CRS node VIP addresses and network interface definitions.

Read More: [Deinstallation Response File Example for Oracle Grid Infrastructure for a Cluster](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/removing-oracle-ai-database-software/deinstallation-response-file-example-for-oracle-grid-infrastructure-for-a-cluster.html)

## Migrating Standalone Oracle Grid Infrastructure Servers to a Cluster

Migration from Oracle Restart to clustered Grid Infrastructure involves documenting databases, services, and listeners with `srvctl`, stopping them, unmounting ACFS, deconfiguring Oracle Restart with `roothas.sh`, and removing its `oratab` entry. The existing home can be unlocked or a new Grid home prepared, with optional reuse of ASM disk groups for OCR, voting files, and the ASM SPFILE. After silent cluster installation and root configuration, remount storage, re-enable ACFS volumes, recreate filesystem, database, and service resources, and add additional cluster nodes as needed.

Read More: [Migrating Standalone Oracle Grid Infrastructure Servers to a Cluster](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/removing-oracle-ai-database-software/migrating-standalone-oracle-grid-infrastructure-servers-to-a-cluster.html)

## Changing the Oracle Grid Infrastructure Home Path

To relocate a clustered Grid home, stop all executables and dependent applications, copy the old binaries to the new path, correct ownership, and run `gridSetup.sh` in software-only mode without changing the Oracle base. Execute the new home’s `root.sh`, relink RAC, dNFS, and `ioracle` components, then use `rootcrs.sh -move` to activate the destination home. Repeat the procedure on every cluster node.

Read More: [Changing the Oracle Grid Infrastructure Home Path](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/removing-oracle-ai-database-software/changing-the-oracle-grid-infrastructure-home-path.html)


# Oracle Grid Infrastructure Command-Line Options

Use this comprehensive list of Oracle Grid Infrastructure silent mode commands to install, configure, patch, upgrade, downgrade, and manage Oracle Grid Infrastructure deployments.

## gridSetup.sh Command

The `gridSetup.sh` command launches the Oracle Grid Infrastructure installer by default and supports general installation, prerequisite, configuration, debugging, patching, response-file, and automated root-script options. Key flags include silent or response-file installation, prerequisite validation, configuration-tool execution, one-off patch application, root or sudo execution methods, and help output.

Read More: [gridSetup.sh Command](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-command.html)

## gridSetup.sh -setupHome

The `gridSetup.sh -setupHome` command installs Oracle Grid Infrastructure software and registers it with the central inventory. It requires SYSDBA and SYSASM operating-system groups and an Oracle base directory, while optionally accepting SYSOPER, cluster-node, inventory-location, prerequisite, and automatic root-script settings.

Read More: [gridSetup.sh -setupHome](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-setuphome.html)

## gridSetup.sh -setupHomeAs

The `gridSetup.sh -setupHomeAs` command installs Oracle Grid Infrastructure using the Oracle base and privileged operating-system groups from a specified source Grid home. Optional parameters allow prerequisite checks, group or Oracle base overrides, target cluster nodes, and automatic root-script execution.

Read More: [gridSetup.sh -setupHomeAs](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-setuphomeas.html)

## gridSetup.sh -configureCluster

The `gridSetup.sh -configureCluster` command configures Oracle Grid Infrastructure for a cluster, including cluster identity, network interfaces, SCAN or GNS, nodes, storage for OCR and voting files, ASM disk groups, extended-cluster sites, automatic fixups, IPMI, Enterprise Manager management, and root-script execution. Required inputs include the cluster name, network interface usage, Oracle base, and, unless the Grid home is already configured, the privileged operating-system groups.

Read More: [gridSetup.sh -configureCluster](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-configurecluster.html)

## gridSetup.sh -switchGridhome

The `gridSetup.sh -switchGridHome` command changes the active Grid Infrastructure home to the current home after software-only installation has been completed on all cluster nodes. It supports zero-downtime patch switching, optional driver-update suppression, rollback to an older home, prerequisite checks, service-drain timeouts, and resuming pending or failed operations; zero-downtime switching and rollback are mutually exclusive.

Read More: [gridSetup.sh -switchGridhome](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-switchgridhome.html)

## gridSetup.sh -upgrade

The `gridSetup.sh -upgrade` command upgrades an earlier Oracle Grid Infrastructure installation to the current release. It supports prerequisite checks, Oracle base selection, dry runs, batch node mappings, skipping unavailable nodes, configuration tools, and automatic root-script execution.

Read More: [gridSetup.sh -upgrade](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-upgrade.html)

## gridSetup.sh -downgrade

The `gridSetup.sh -downgrade` command reverts Oracle Grid Infrastructure to an earlier release following a failed upgrade. It requires the path to the earlier Grid home and optionally runs configuration tools and the root script automatically.

Read More: [gridSetup.sh -downgrade](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-downgrade.html)

## gridSetup.sh -createGoldImage

The `gridSetup.sh -createGoldImage` command creates a reusable gold image from the current Oracle Grid Infrastructure home. It requires a destination directory and optionally accepts comma-separated absolute file or directory paths, including wildcarded directories, to exclude from the image.

Read More: [gridSetup.sh -createGoldImage](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-creategoldimage.html)

## gridSetup.sh -addNode

The `gridSetup.sh -addNode` command adds specified nodes to an existing cluster. It requires a comma-separated list of new node names and optionally performs prerequisite checks and automatic root-script execution; each node name must be unique within the cluster.

Read More: [gridSetup.sh -addNode](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-addnode.html)

## gridSetup.sh -deleteNode

The `gridSetup.sh -deleteNode` command removes specified remote nodes from an Oracle cluster. It requires a list of nodes to delete and cannot be used to remove the local node.
Read More: [gridSetup.sh -deleteNode](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/oracle-grid-infrastructure-command-line-options/gridsetup.sh-deletenode.html)


# Response Files

## Reasons for Using Silent Mode or Response File Mode

Oracle Universal Installer response files automate Oracle software installation and configuration across multiple systems. Silent mode uses answers for all prompts and displays only terminal progress, making it suitable for unattended, scheduled, repeated, or non-GUI installations. Response file mode supplies answers for some or all prompts while displaying installer screens for completion or review.

Read More: \[Reasons for Using Silent Mode or Response File Mode\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/response-files/reasons-for-using-silent-mode-or-response-file-mode.html)

## Using Response Files

To install and configure Oracle products with response files, complete all required preinstallation tasks, prepare the response file, run the installer in silent or response file mode, and execute root scripts when prompted. For software-only installations, run Net Configuration Assistant and Oracle DBCA afterward in the appropriate automated mode to create the listener and database.

Read More: \[Using Response Files\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/response-files/using-response-files.html)

## Preparing Response Files

Prepare response files by copying the appropriate Oracle template, editing its variables according to the included instructions, retaining the `.rsp` suffix, and securing the file with permission mode 600 because it may contain passwords. Templates support Oracle AI Database, Grid Infrastructure, Database Client, DBCA, and Net Configuration Assistant. Alternatively, record a response file during an interactive installation from the Summary page, then review and modify it for reuse; recorded files do not contain passwords.

Read More: \[Preparing Response Files\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/response-files/preparing-response-files.html)

## Running Oracle Universal Installer Using a Response File

Run `runInstaller` for Oracle AI Database or Database Client, or `gridSetup.sh` for Grid Infrastructure, with `-responseFile` and the full path to the configured response file; add `-silent` to suppress installer screens. Complete normal prerequisites, use the software owner account, and set `DISPLAY` only for response file mode. Do not use a relative response-file path, and run `orainstRoot.sh` during the first installation and `root.sh` after installation as root when prompted.

Read More: \[Running Oracle Universal Installer Using a Response File\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/response-files/running-oracle-universal-installer-using-a-response-file.html)

## Postinstallation Configuration Using Response File Created During Installation

Use an installation response file to run postinstallation configuration assistants with `-executeConfigTools` for Oracle Grid Infrastructure or Oracle AI Database. Before execution, add the required database, ASM, management, or Grid Infrastructure passwords, secure the file with mode 600, and restrict ownership to the installation user and inventory group. Run the appropriate `gridSetup.sh` or `runInstaller` command from the Oracle home, optionally adding `-silent` to suppress configuration screens; the process can configure one or more servers.
Read More: \[Postinstallation Configuration Using Response File Created During Installation\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/response-files/postinstallation-configuration-using-response-file-created-during-installation.html)


# Completing Preinstallation Tasks Manually

Oracle recommends that you use Oracle Universal Installer and Configuration Verification Utility (CVU) fixup scripts to complete minimal configuration settings. If you cannot use fixup scripts, then complete minimum system settings manually.

## Configuring SSH Manually on All Cluster Nodes

Passwordless SSH is mandatory for Oracle Grid Infrastructure installation and supports configuration assistants, Enterprise Manager, OPatch, and other tools. For each software owner, such as `grid` or `oracle`, verify OpenSSH is running, create a private `.ssh` directory with mode 700, generate RSA or DSA key pairs using the required format, and protect private keys. Combine every node’s public key into a shared `authorized_keys` file, distribute the identical file to all nodes, and verify connectivity between every node—including the local node—using `ssh hostname date` without password prompts. If authentication fails, check key contents, file permissions, and consistent user, group, and ID configuration across the cluster.

Read More: \[Configuring SSH Manually on All Cluster Nodes\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/completing-preinstallation-tasks-manually/configuring-ssh-manually-on-all-cluster-nodes.html)

## Configuring Storage Device Path Persistence Manually

Manual Oracle ASM device persistence requires custom `udev` rules so device names, ownership, groups, and permissions remain consistent after reboots. Obtain stable SCSI identifiers with `scsi_id`, enable trusted device identification through `/etc/scsi_id.config`, and create rules under `/etc/udev/rules.d/` with `OWNER`, `GROUP`, and `MODE` specified before other attributes. Set ASM devices to the appropriate installation owner and OSDBA group with mode 0660, copy the rules file to every cluster node, run `partprobe`, test the rules with `udevtest`, reload or restart the `udev` service according to the Linux distribution, and verify resulting device ownership and permissions.

Read More: \[Configuring Storage Device Path Persistence Manually\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/completing-preinstallation-tasks-manually/configuring-storage-device-path-persistence-manually.html)

## Configuring Kernel Parameters for Linux

When fixup scripts or the preinstallation RPM are unavailable, configure Linux kernel parameters manually using the recommended minimums for semaphores, shared memory, file handles, asynchronous I/O, network buffers, ephemeral ports, panic handling, and related resources. Inspect current values with `sysctl`, persist required changes in `/etc/sysctl.d/97-oracle-database-sysctl.conf`, apply them with `sysctl --system`, and verify the results without lowering values already above the minimums. Account for higher RAC workloads, avoid conflicting parameter files, and use appropriate SUSE-specific settings for `boot.sysctl` and `vm.hugetlb_shm_group`. Configure ephemeral ports with a range beginning at 9000 or higher and using suitable even/odd boundaries, then make the setting persistent.

Read More: \[Configuring Kernel Parameters for Linux\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/completing-preinstallation-tasks-manually/configuring-kernel-parameters-for-linux.html)

## Configuring Default Thread Limits Value for SUSE Linux

On SUSE Linux Enterprise Server 15 and later, increase the systemd `DefaultTasksMax` value from its typical default of 512 to 65535 to prevent service failures caused by thread limits. Check the current value using `/etc/systemd/system.conf` or `systemctl show --property DefaultTasksMax`, update and uncomment the setting if necessary, and apply the change by rebooting or running `systemctl daemon-reload`.
Read More: \[Configuring Default Thread Limits Value for SUSE Linux\](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/completing-preinstallation-tasks-manually/configuring-default-thread-limits-value-for-suse-linux.html)


# Optimal Flexible Architecture

## About the Optimal Flexible Architecture Standard

Oracle Optimal Flexible Architecture (OFA) provides configuration guidelines for organizing Oracle software, databases, permissions, and files consistently. It simplifies administration, maintenance, support, expansion, and coexistence of multiple databases and software versions. Oracle recommends accepting the installer’s OFA defaults, particularly for large or multi-database environments, because OFA also helps associate Oracle bases with Automatic Diagnostic Repository data for incident collection.

Read More: [About the Optimal Flexible Architecture Standard](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/optimal-flexible-architecture/about-the-optimal-flexible-architecture-standard.html)

## About Multiple Oracle Homes Support

Oracle AI Database supports installing multiple releases and database versions on one system, provided each release uses a separate Oracle home and products are not mixed across release homes. Extract the installation image and run the setup wizard independently for each home. OFA-compliant directory structures simplify administration, protect user home directories, and support concurrent databases owned by different users. Later releases can access earlier databases only for upgrades, such as starting an earlier database in upgrade mode.

Read More: [About Multiple Oracle Homes Support](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/optimal-flexible-architecture/about-multiple-oracle-homes-support.html)

## About the Oracle Inventory Directory and Installation

The Oracle Inventory directory records all Oracle software installations and must be writable by installation owners through the OINSTALL group. Existing installations reuse the inventory identified by `/etc/oraInst.loc`; new installations select its location from ORACLE\_BASE, an available OFA path, or the installation owner’s home directory. Typical layouts place the inventory above the Oracle base, while Grid Infrastructure separates the Grid base from the Grid home because the Grid home becomes root-owned after installation. Without ORACLE\_BASE or an OFA path, Oracle places the inventory and software under the installing user’s home directory.

Read More: [About the Oracle Inventory Directory and Installation](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/optimal-flexible-architecture/about-the-oracle-inventory-directory-and-installation.html)

## Oracle Base Directory Naming Convention

Oracle base directories should follow the pattern mount-point/standard-directory/owner, such as `/u01/app/oracle` or `/u01/app/grid`. A base can support multiple installations, but each operating-system installation owner should have a separate base and preferably a unique account for clear log separation. Oracle recommends using a consistent mount-point and standard-directory path for all owners, and neither Oracle bases nor their parent directories may be symbolic links.

Read More: [Oracle Base Directory Naming Convention](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/optimal-flexible-architecture/oracle-base-directory-naming-convention.html)

## Oracle Home Directory Naming Convention

Oracle home directories use an OFA pattern consisting of a mount point, standard directory, owner, product path, software version, installation type, and optional installation counter. A typical database home is `/u01/app/oracle/product/23.0.0/dbhome_1`, with variations such as client, grid, or additional numbered homes. Oracle homes, Oracle bases, and all their parent directories up to root must not be symbolic links.

Read More: [Oracle Home Directory Naming Convention](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/optimal-flexible-architecture/oracle-home-directory-naming-convention.html)

## Optimal Flexible Architecture File Path Examples

OFA-compliant layouts organize inventories, Oracle bases, administration files, recovery areas, data files, product homes, and Grid Infrastructure homes across structured directories and multiple mount points. They support multiple database and client homes while distinguishing standalone Grid Infrastructure from clustered Grid homes, whose deployment options cannot coexist and whose ownership changes to root after installation. Oracle recommends ASM for redundancy and throughput and cautions against storing private or application files within OFA directories.
Read More: [Optimal Flexible Architecture File Path Examples](https://docs.oracle.com/en/database/oracle/oracle-database/26/cwlin/optimal-flexible-architecture/optimal-flexible-architecture-file-path-examples.html)