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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.