Patching and Upgrading Oracle AI Database

Patching Oracle AI Database

Fleet Patching and Provisioning patches Oracle AI Database by moving databases to newly patched Oracle homes with rhpctl move database. Patching is performed out-of-place, preserves configuration for rollback, and uses rolling mode by default to minimize downtime; non-rolling or forced rolling modes are available when required. FPP also handles Datapatch, except for Data Guard standbys, and supports moving databases to lower, equal, or higher patch levels. The standard workflow is to create and patch a working copy, validate it, create a gold image, reprovision the patched home, move the database, and retain or delete the original working copy according to rollback requirements.

Patching Oracle Data Guard Database

Starting with Grid Infrastructure 26ai, Fleet Patching and Provisioning can automatically discover and patch Data Guard standby databases before patching their primary database through a single rhpctl move database operation. Administrators query the working copy to identify the Data Guard configuration, schedule the primary and standby patching with -patchdataguard YES, and monitor the parent job or individual operations using rhpctl query job. Data Guard registrations across different clients or data centers require the servers to be registered as peers.

Upgrading Oracle AI Database

Fleet Patching and Provisioning supports traditional database upgrades with rhpctl upgrade database and minimal- or no-downtime RAC upgrades with rhpctl zdtupgrade database. It supports provisioning and patching Oracle Database 19c and later, including upgrades from 19c and 21c to Oracle AI Database 26ai, subject to supported paths and Grid Infrastructure compatibility. Upgrades can target an existing or newly created working copy, and managed source homes support rollback until the source working copy is deleted. Oracle AutoUpgrade, or Replay Upgrade, is required for upgrades to 26ai; other utilities such as DBUA and dbupgrade are desupported.

Patching Oracle True Cache Using Oracle FPP

Oracle Fleet Patching and Provisioning patches standalone-node Oracle True Cache deployments by provisioning a patched working copy, moving the True Cache database to it with rhpctl move database, and restarting the database from the new Oracle home. Verification can be performed through /etc/oratab or by examining the running PMON process executable path. The resolved path must reference the patched home, and cache warm-up is not performed automatically because its duration depends on workload, table size, and caching requirements.

Zero-Downtime Upgrade

Fleet Patching and Provisioning provides a resumable and recoverable zero-downtime upgrade process for Oracle RAC and RAC One Node, although this ZDU feature is deprecated in Oracle AI Database 19c in favor of FPP combined with DBMS_ROLLING and Application Continuity. ZDU supports specified upgrade paths through 26ai for archive-log databases, whether the source home is managed or unmanaged, and can use Oracle GoldenGate or Data Guard replication. It supports CDB upgrades but not non-CDB-to-CDB conversion, and provides validation, restart, recovery, and user-script hooks. The environment requires compatible Grid Infrastructure and FPP components plus either snap-clone or full-copy storage for local replicated data.

Running a Zero-Downtime Upgrade Using Oracle GoldenGate for Replication

This procedure describes the deprecated FPP zero-downtime upgrade method using Oracle GoldenGate replication. Administrators import GoldenGate software homes as FPP gold images, provision corresponding working copies on the target client or cluster, provision the destination database home, and run rhpctl zdtupgrade database with the source and destination GoldenGate working copies. Working copy names must be unique across clients and targets, and preparation can occur before the maintenance window to avoid operational disruption.

Running a Zero-Downtime Upgrade Using Oracle Data Guard for Replication

The deprecated FPP zero-downtime upgrade method using Data Guard relies on a transient logical standby, with FPP orchestrating cloning, upgrade, validation, role transitions, flashback, recovery, and cleanup. Before execution, the destination database home must be provisioned, Data Guard Broker must be disabled, and the flash recovery area must be configured. The rhpctl zdtupgrade database command upgrades the primary database with minimal service interruption by upgrading the transient standby, switching roles, converting the former primary to a physical standby, recovering it, and switching back.

Customizing Zero-Downtime Upgrades

Fleet Patching and Provisioning allows deprecated zero-downtime upgrades to be customized through user actions that run before or after major stages, including the overall upgrade, snapshot or full-clone creation, DBUA execution, and switchback. Administrators register scripts with rhpctl add useraction, selecting the operation type and pre- or post-action phase, and can pass runtime data through the -useractiondata option of rhpctl zdtupgrade database.
Read More: Customizing Zero-Downtime Upgrades