# Oracle Fleet Patching and Provisioning Administrator's Guide

This file contains the text from each Oracle Fleet Patching and Provisioning Administrator's Guide article landing page, release 26ai.

# Oracle Fleet Patching and Provisioning

## About Oracle Fleet Patching and Provisioning

Oracle Fleet Patching and Provisioning (Oracle FPP) is a gold-image-based lifecycle management solution for provisioning, patching, upgrading, scaling, and maintaining Oracle Grid Infrastructure, Oracle AI Database, clusters, applications, middleware, and user-defined software. It supports Local Mode for simplified, setup-free operations and Server Mode for centrally managing large fleets across data centers. Oracle FPP provides out-of-place and rolling patching, standardization, rollback, resumable operations, scheduling, validation, dry runs, REST APIs, customizable workflows, session management, and integration with Exadata software stacks. It reduces downtime and operational risk while supporting centralized image management, deployment lineage, and automated maintenance; however, it is not supported on HP-UX or Windows, and certain standalone combined-patching scenarios are excluded.

Read More: \[About Oracle Fleet Patching and Provisioning\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning/about-oracle-fleet-patching-and-provisioning.html)

## Oracle Fleet Patching and Provisioning Features

Oracle Fleet Patching and Provisioning provides patching and upgrade capabilities for Oracle AI Database, Oracle RAC, Oracle RAC One Node, single-instance databases, Grid Infrastructure, Oracle Restart, and Exadata components, along with operating-system configuration monitoring. Its deployment models include Local Mode and a centralized Server Mode, while fleet-scale jobs, tagging, scheduling, notifications, REST APIs, configurable connectivity, and customizable authentication support large automated estates. Additional capabilities include peer image sharing, gold-image drift detection, configuration collection, external metadata repositories, arbitrary software-home provisioning, pre-checks, adaptive RAC rolling patching, combined Grid Infrastructure and database patching, batch and smart rolling updates, Application Continuity integration, custom workflows, resumable operations, and auditing.

Read More: \[Oracle Fleet Patching and Provisioning Features\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning/oracle-fleet-patching-and-provisioning-features.html)

## Oracle Fleet Patching and Provisioning Architecture

Oracle Fleet Patching and Provisioning architecture consists of a highly available Oracle FPP Server, Oracle FPP Clients, and clientless targets. The Server should run on a multi-node Oracle Clusterware cluster and centrally stores gold images, working copies, client information, and metadata for users, roles, permissions, and identities. It provisions Oracle homes and other software to clients and targets through technologies such as Oracle ACFS and local file systems, supports physical and virtual servers, maintains inventories and audit records, and distributes standardized homes. Clients, integrated with Oracle Clusterware and the `rhpclient` component, request images and initiate operations, while clientless targets can be provisioned and managed directly by the Server. From Oracle Grid Infrastructure 26ai, the Server can use a local or external metadata repository, with separate repositories required when multiple Servers share a database container.

Read More: \[Oracle Fleet Patching and Provisioning Architecture\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning/oracle-fleet-patching-and-provisioning-architecture.html)

## Oracle Fleet Patching and Provisioning Concepts

Oracle Fleet Patching and Provisioning organizes deployable software as gold images and working copies. A gold image is a reusable copy of an Oracle home that can be provisioned to new hosts and may be restricted for testing or validation before general availability. Related images can be grouped into gold image series by release, publisher, department, or other organizational criteria. A working copy is an instantiated copy of a gold image deployed on the Oracle FPP Server, an Oracle FPP Client, or a clientless target, providing the usable software home for database, Grid Infrastructure, or other software deployment.

Read More: \[Oracle Fleet Patching and Provisioning Concepts\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning/oracle-fleet-patching-and-provisioning-concepts.html)

## About Oracle Update Advisor

Oracle Update Advisor automates evaluation and patch recommendations for Oracle Grid Infrastructure and Oracle AI Database homes in both Oracle FPP Local Mode and Server Mode. After user registration through Oracle Single Sign-On, it assesses a specified home or gold image and recommends patches for security, stability, and performance. Existing images return synchronous health and patch information, while custom image requests return asynchronous status details and request identifiers. Local Mode requires separate evaluation and image download steps, whereas Server Mode can evaluate, download, and import a patched image into the gold-image repository as part of the workflow.

Read More: \[About Oracle Update Advisor\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning/about-oracle-update-advisor.html)


# Oracle Fleet Patching and Provisioning Local Mode

## About Oracle Fleet Patching and Provisioning Local Mode

Oracle Fleet Patching and Provisioning Local Mode is enabled by default with Oracle Grid Infrastructure and provides local-cluster patching for Oracle Grid Infrastructure and Oracle AI Database without requiring a Java container, separate server, or additional setup. It supports clustered Oracle Database 11.2.0.4, 12.1.0.2, 12.2.0.1, and later releases, while standalone environments support only Oracle Database 18c and later database-home patching. Patching uses deployed source and destination homes with the rhpctl move gihome or rhpctl move database commands, and configuring a central Oracle FPP Server requires removing the Local Mode configuration.

Read More: [About Oracle Fleet Patching and Provisioning Local Mode](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-local-mode/about-oracle-fleet-patching-and-provisioning-local-mode.html)

## Performing Patching Using Oracle FPP Local Mode

Patching with Oracle FPP Local Mode consists of deploying new Grid Infrastructure and database homes, switching to them with rhpctl move gihome and rhpctl move database, and optionally rolling back by reversing the Grid Infrastructure home move. Only one patching operation can run at a time, and the command must be initiated from a single node; completion propagates automatically to other nodes. If the initial command fails, it must be rerun from the same node where it began.

Read More: [Performing Patching Using Oracle FPP Local Mode](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-local-mode/performing-patching-using-oracle-fpp-local-mode.html)

## Using Oracle Update Advisor in Oracle FPP Local Mode

Oracle Update Advisor in FPP Local Mode allows administrators to register a user, evaluate an Oracle home against an update policy, receive patch recommendations, generate a patched image, monitor the evaluation request, and download the resulting gold image. The downloaded image can then be deployed and used for patching according to the Local Mode procedure. With Oracle Restart, Local Mode supports patching the Oracle AI Database home but not the Oracle Grid Infrastructure home.

Read More: [Using Oracle Update Advisor in Oracle FPP Local Mode](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-local-mode/using-oracle-update-advisor-in-oracle-fpp-local-mode.html)

## Storing User-Action Scripts in OCR for Oracle FPP Local Mode

Starting with Oracle Grid Infrastructure 26ai, user-action script locations for Oracle FPP Local Mode can be stored in the Oracle Cluster Registry using the rhphelper command. This avoids specifying the script location for every Grid Infrastructure or Oracle AI Database patch operation, and the stored value is readable by both the grid and oracle users. The ualoc parameter can optionally override the OCR-defined location for an individual patch operation, while an empty location resets the stored value.

Read More: [Storing User-Action Scripts in OCR for Oracle FPP Local Mode](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-local-mode/storing-user-action-scripts-in-ocr-for-oracle-fpp-local-mode.html)

## Switching from Oracle FPP Local Mode to Oracle FPP Central Server

Oracle FPP Local Mode starts automatically when a patching command is invoked and its dependent resources are configured during startup. To switch to Oracle FPP Central Server mode, stop and remove the local rhpserver resource with srvctl, then follow the central-server creation procedure to deploy the Oracle FPP Server for managing clients and rhpclient-less targets.
Read More: [Switching from Oracle FPP Local Mode to Oracle FPP Central Server](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-local-mode/switching-from-oracle-fpp-local-mode-to-oracle-fpp-central-server.html)


# Oracle Fleet Patching and Provisioning Central Mode

## Configuring Oracle Fleet Patching and Provisioning Server

Central-mode configuration requires an Oracle Clusterware-based Grid Infrastructure cluster, compatible ACFS kernel support, at least 100 GB of ASM storage, an application VIP, accessible communication ports, and optionally custom certificates or an external metadata repository. The server is created by preparing shared storage and a mount path, removing default Local Mode, configuring the metadata repository, adding the FPP server resource with appropriate networking, storage, database, TLS, and listener settings, and starting the resource. Required ports include JMX port 8896, SSH port 22 for initial client deployment, bidirectional image-transfer and progress-listener ranges, and UDP 53 when using GNS or the application VIP. Existing deployments can switch from GNS to the application VIP by modifying the server, exporting and applying updated client data files, restarting each client, and then removing GNS.

Read More: [Configuring Oracle Fleet Patching and Provisioning Server](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-central-mode/configuring-oracle-fleet-patching-and-provisioning-server.html)

## Configuring Oracle Fleet Patching and Provisioning Clients

FPP client setup involves generating a client data file on the server, transferring it to the client cluster, optionally configuring custom TLS certificates, and adding the client with `srvctl`, including an optional ASM disk group and storage base path for ACFS working copies. After starting and verifying the client, administrators can enable or disable it from the server with `rhpctl modify client`; disabling rejects new client commands but does not affect existing working copies or running databases. Client deletion requires first removing all working copies and registered users on the server, then stopping and removing the client configuration locally and deleting the client site configuration from the server.

Read More: [Configuring Oracle Fleet Patching and Provisioning Clients](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-central-mode/configuring-oracle-fleet-patching-and-provisioning-clients.html)

## Oracle Fleet Patching and Provisioning Server Self-Upgrade

The FPP Server self-upgrade procedure upgrades Grid Infrastructure to 26ai by first importing Oracle AI Database and Grid Infrastructure 26ai images, creating corresponding database and software-only working copies, and backing up the existing FPP metadata. Administrators then prepare the new Grid home, run the prerequisite ownership script, evaluate the upgrade in batches with the first batch containing one node, and resolve any reported issues. The upgrade is executed using batched `rhpctl upgrade gihome` commands, followed by a continuation command if required; the process removes the desupported GIMR and migrates FPP metadata to the new `fpprepos` single-instance database.

Read More: [Oracle Fleet Patching and Provisioning Server Self-Upgrade](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-central-mode/oracle-fleet-patching-and-provisioning-server-self-upgrade.html)

## Migrating Metadata from GIMR to Metadata Repository for Manual Upgrade

After a manual Grid Infrastructure upgrade to 26ai, existing FPP metadata must be migrated because GIMR is desupported and FPP requires a central metadata repository. Before removing GIMR, administrators must export its metadata, configure a licensed single-instance Oracle AI Database or Oracle RAC One Node repository across all active cluster nodes, and run `reposScript.sh` in Upgrade mode with the source version, export directory, database home, and metadata disk group to import the saved metadata.

Read More: [Migrating Metadata from GIMR to Metadata Repository for Manual Upgrade](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-central-mode/migrating-metadata-from-gimr-to-metadata-repository-for-manual-upgrade.html)

## Oracle Fleet Patching and Provisioning Backup and Restore

Oracle FPP supports full server backups and restores using local or NFS storage, enabling disaster recovery or relocation to new hardware. A backup is a timestamped ZIP containing metadata, credentials, registered operating-system users, gold images, and user actions; it requires an empty writable destination, no active operations, and should be stored outside the protected cluster. Restore requires matching Grid Infrastructure and RU versions, clears or excludes incomplete work, working copies, moves, and affected jobs, and may restore in place or relocate services based on the cluster name. Relocation involves restoring the backup on the new server, transferring updated client data files to clients, validating connectivity, and converting the former server into a client after all other clients have moved.
Read More: [Oracle Fleet Patching and Provisioning Backup and Restore](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-central-mode/oracle-fleet-patching-and-provisioning-backup-and-restore.html)


# Managing Gold Images and Working Copies

## Adding Gold Images to the Fleet Patching and Provisioning Server

Oracle Fleet Patching and Provisioning stores read-only gold images that must be converted into working copies before use as software homes. Images can be imported from installed homes on the server or client, or from zip files with optional zipcopy support to avoid transferring files to destinations. Image states such as TESTABLE, RESTRICTED, and PUBLISHED control provisioning access; image series organize images in ordered logical groups; and image types identify software categories, including built-in and custom types based on Oracle-supported types.

Read More: [Adding Gold Images to the Fleet Patching and Provisioning Server](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/managing-gold-images-and-working-copies/adding-gold-images-to-the-fleet-patching-and-provisioning-server.html)

## Provisioning Copies of Gold Images

RHPCTL provisions gold-image working copies to Fleet Patching and Provisioning Servers, Clients, and rhpclient-less targets, either from repository images or locally available zip files. Working copies can be stored on managed Oracle ACFS or local file systems, with local mounting and location options avoiding unnecessary transfers. Destination paths must be empty, and interrupted provisioning operations can be rerun to resume after errors.

Read More: [Provisioning Copies of Gold Images](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/managing-gold-images-and-working-copies/provisioning-copies-of-gold-images.html)

## Provisioning Oracle Grid Infrastructure Homes

Fleet Patching and Provisioning distributes Oracle Grid Infrastructure homes as working copies and can optionally configure new installations, including single-node, clustered, and Oracle Restart deployments. It supports provisioning software-only homes to systems with existing managed or unmanaged Grid homes, enabling later activation, patching, upgrading, switching, reverting, and node-management operations. Response files define target nodes and configuration details, while targetnode is used for rhpclient-less systems and client identifies supported FPP Clients.

Read More: [Provisioning Oracle Grid Infrastructure Homes](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/managing-gold-images-and-working-copies/provisioning-oracle-grid-infrastructure-homes.html)

## Provisioning Oracle AI Database Homes

The rhpctl add workingcopy command provisions Oracle AI Database software working copies to FPP Servers, Clients, or rhpclient-less targets. The command specifies the source gold image, working-copy name, destination path, Oracle base, and target client or nodes; all specified destination directories must be empty.

Read More: [Provisioning Oracle AI Database Homes](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/managing-gold-images-and-working-copies/provisioning-oracle-ai-database-homes.html)

## Creating an Oracle AI Database

Oracle Fleet Patching and Provisioning can create Oracle AI Database instances on provisioned working copies located on the Server, a Client, or a rhpclient-less target. The rhpctl add database command supports administrator-managed RAC, RAC One Node, and noncluster databases, with data files placed in a prepared destination such as an Oracle ASM disk group. SYS and SYSTEM passwords are generated randomly and cannot be retrieved, so they must be reset locally by an appropriately privileged user.

Read More: [Creating an Oracle AI Database](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/managing-gold-images-and-working-copies/creating-an-oracle-ai-database.html)

## Archiving and Unarchiving Gold Images

Oracle Grid Infrastructure 26ai allows gold images to be archived as zip files to reclaim disk space without deleting them and later restored when needed. An image can be archived only when it has no working copies, archived images cannot create working copies, and archiving changes the image state to ARCHIVED. The rhpctl archive image and rhpctl unarchive image commands perform these operations.
Read More: [Archiving and Unarchiving Gold Images](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/managing-gold-images-and-working-copies/archiving-and-unarchiving-gold-images.html)


# Patching and Upgrading Oracle Grid Infrastructure

## Patching Oracle Grid Infrastructure

Oracle Fleet Patching and Provisioning supports rolling, non-rolling, combined Grid Infrastructure and database patching, and zero-downtime Grid Infrastructure patching. Rolling moves the Grid home sequentially across nodes with `rhpctl move gihome`, while non-rolling restarts all nodes in parallel and is limited to single-node clusters. Operations can resume after failure or be reverted when using managed working copies, although aborting may leave the environment inconsistent and deleting the source working copy prevents rollback. Combined operations can move Grid and selected database homes together. Zero-downtime patching supports out-of-place 19c RU 19.8 and later deployments with compatible databases, but updates only Grid user-space binaries; operating-system drivers and modules require separate installation and node restarts.

Read More: \[Patching Oracle Grid Infrastructure\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-grid-infrastructure/patching-oracle-grid-infrastructure.html)

## Upgrading Oracle Grid Infrastructure

Fleet Patching and Provisioning can upgrade Oracle Grid Infrastructure to 26ai from 19c or 21c by moving the cluster from a source working copy to a provisioned destination working copy with `rhpctl upgrade gihome`. For unmanaged source homes, specify the source path and cluster name instead of a working-copy name. The source working copy may be deleted after the upgrade, but doing so removes rollback capability; it should be deleted through `rhpctl delete workingcopy` to preserve inventory consistency.

Read More: \[Upgrading Oracle Grid Infrastructure\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-grid-infrastructure/upgrading-oracle-grid-infrastructure.html)

## Oracle Restart Patching and Upgrading

Oracle Fleet Patching and Provisioning patches or upgrades single-node Oracle Restart environments using gold-image-provisioned homes. During a move, it transfers configuration files such as `listener.ora` and updates the associated configuration and inventory settings. Use `rhpctl move gihome` to patch an Oracle Restart home and `rhpctl upgrade gihome` to move to a higher-version home, specifying the source and destination working copies, target node, and required superuser credentials.

Read More: \[Oracle Restart Patching and Upgrading\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-grid-infrastructure/oracle-restart-patching-and-upgrading.html)

## Using Oracle Update Advisor in Oracle FPP Server Mode

Oracle Update Advisor in FPP Server Mode evaluates gold images or Oracle homes, recommends patch levels according to update policies, downloads the recommended patched image, and imports it into an existing gold image. The workflow requires registering an Update Advisor user, running `rhpctl evaluate patch` to assess or generate an image, monitoring the scheduled job with `rhpctl query job`, and then applying the resulting image through the standard Oracle AI Database or Grid Infrastructure patching procedures. Images are downloaded to Oracle ACFS, and job output reports health status, recommendations, download progress, and import results.
Read More: \[Using Oracle Update Advisor in Oracle FPP Server Mode\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-grid-infrastructure/using-oracle-update-advisor-in-oracle-fpp-server-mode.html)


# 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.

Read More: \[Patching Oracle AI Database\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-ai-database/patching-oracle-ai-database.html)

## 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.

Read More: \[Patching Oracle Data Guard Database\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-ai-database/patching-oracle-data-guard-database.html)

## 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.

Read More: \[Upgrading Oracle AI Database\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-ai-database/upgrading-oracle-ai-database.html)

## 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.

Read More: \[Patching Oracle True Cache Using Oracle FPP\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-ai-database/patching-oracle-true-cache-using-oracle-fpp.html)

## 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.

Read More: \[Zero-Downtime Upgrade\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-ai-database/zero-downtime-upgrade.html)

## 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.

Read More: \[Running a Zero-Downtime Upgrade Using Oracle GoldenGate for Replication\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-ai-database/running-a-zero-downtime-upgrade-using-oracle-goldengate-for-replication.html)

## 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.

Read More: \[Running a Zero-Downtime Upgrade Using Oracle Data Guard for Replication\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-ai-database/running-a-zero-downtime-upgrade-using-oracle-data-guard-for-replication.html)

## 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\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/patching-and-upgrading-oracle-ai-database/customizing-zero-downtime-upgrades.html)


# Updating Oracle Exadata Infrastructure

## About Oracle Exadata Infrastructure Patching

Oracle Fleet Patching and Provisioning supports rolling patches for Exadata storage cells, network switches, and database nodes. Patching can be driven from the FPP Server with passwordless root SSH access, or from an FPP Client after deploying the required image. Both workflows include evaluation prechecks and use rhpctl update exadata for execution; cell server and database node patches can be rolled back, while switch patches can be downgraded if necessary.

Read More: \[About Oracle Exadata Infrastructure Patching\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/about-oracle-exadata-infrastructure-patching.html)

## Updating Oracle Exadata Storage Server

Updating an Exadata storage server requires importing an EXAPATCHSOFTWARE image with the exact patchmgr-compatible version, deploying it to the client cluster when patching from an FPP Client, and running rhpctl update exadata first with the eval option for prechecks and then without it to apply the update. The operation targets specified storage cells and may include patch manager options and a driving system. The resulting image can be verified with rhpctl query image.

Read More: \[Updating Oracle Exadata Storage Server\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/updating-oracle-exadata-storage-server.html)

## Rolling Back Oracle Exadata Storage Server Patch

To roll back a successfully updated Exadata storage server, first verify its current patch version, run rhpctl update exadata with the target cells, image, client, and patch manager arguments, and then verify that the storage server has returned to its previous software version.

Read More: \[Rolling Back Oracle Exadata Storage Server Patch\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/rolling-back-oracle-exadata-storage-server-patch.html)

## Updating Oracle Exadata Database Node

Updating Exadata database nodes requires the latest Patch Manager, an imported EXAPATCHSOFTWARE image containing the required update files, and image deployment to the client when patching from an FPP Client. Perform evaluation checks, ensuring the image path includes both the database node ISO ZIP and dbnodeupdate.zip or specify patchmgrloc, then back up the current configuration and apply the update with rhpctl update exadata. The operation supports node batches, automatic discovery of active nodes, and full live updates for Exadata 24.1 and later; results can be reviewed with rhpctl query client.

Read More: \[Updating Oracle Exadata Database Node\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/updating-oracle-exadata-database-node.html)

## Rolling Back Oracle Exadata Database Node Patch

To roll back an Exadata database node patch, check the current patch version, execute rhpctl update exadata with the affected nodes, image, client, Patch Manager location, and rollback option, and then verify that the previous database node software version has been restored.

Read More: \[Rolling Back Oracle Exadata Database Node Patch\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/rolling-back-oracle-exadata-database-node-patch.html)

## Updating Oracle Exadata RoCE Switches

Updating Exadata RDMA over Converged Ethernet switches involves importing an exact patchmgr-compatible EXAPATCHSOFTWARE image, deploying it to the client cluster when required, and running rhpctl update exadata with the RoCE switch list and eval option for prechecks. Run the command again without eval to apply the firmware, then use rhpctl query image to confirm that the image is identified as an Exadata network switch image.

Read More: \[Updating Oracle Exadata RoCE Switches\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/updating-oracle-exadata-roce-switches.html)

## Downgrading Oracle Exadata RoCE Switches

To downgrade successfully updated RoCE switches, verify the current firmware version, perform pre-downgrade checks with rhpctl update exadata and the downgrade plus eval options, and then repeat the command without eval to apply the downgrade. Confirm the final firmware version after completion.

Read More: \[Downgrading Oracle Exadata RoCE Switches\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/downgrading-oracle-exadata-roce-switches.html)

## Updating Oracle Exadata InfiniBand Switches

Updating Exadata InfiniBand switches requires importing an exact patchmgr-compatible EXAPATCHSOFTWARE image and deploying it to the client cluster when patching from a client. Run rhpctl update exadata with the InfiniBand switch list and eval for prechecks, then repeat without eval to apply the firmware. Specify patchmgrdrivingsystem when the FPP Server lacks direct switch access and an intermediary dom0 node is required; image type can be verified with rhpctl query image.

Read More: \[Updating Oracle Exadata InfiniBand Switches\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/updating-oracle-exadata-infiniband-switches.html)

## Downgrading Oracle Exadata InfiniBand Switches

To downgrade InfiniBand switches, verify the current firmware, run pre-downgrade evaluation with rhpctl update exadata using the downgrade and eval options, and then execute the same command without eval to perform the downgrade. Check the firmware version afterward to confirm success.

Read More: \[Downgrading Oracle Exadata InfiniBand Switches\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/downgrading-oracle-exadata-infiniband-switches.html)

## Combined Oracle Exadata Database Server and Grid Infrastructure Update

The combined update integrates Exadata database node patching with Grid Infrastructure patching, reducing downtime by requiring only one database shutdown and startup sequence per node. Create the Exadata update image once on the FPP Server, deploy it to each target server without downtime, and use rhpctl move gihome to process database node patching and Grid Infrastructure home movement in batches. FPP patches each database node first with patchmgr and then patches Grid Infrastructure, supports parallel processing within batches, and allows the operation to resume after recovery from patchmgr failures or timeouts.
Read More: \[Combined Oracle Exadata Database Server and Grid Infrastructure Update\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/combined-oracle-exadata-database-server-and-grid-infrastructure-update.html)


# Fleet Patching and Provisioning Postinstallation Tasks

## Authentication Options for Oracle Fleet Patching and Provisioning Operations

Authentication is handled automatically between trusted Oracle Fleet Patching and Provisioning Servers and Clients, except when provisioning a new Grid Infrastructure deployment before the client exists. Operations on client-less targets require root or sudo credentials supplied interactively, from an encrypted store, through stored credentials, or by SSH key. Passwordless SSH requires user equivalence between the server’s crsusr account and root or a privileged target user, with authentication parameters specifying the user, identity file, and optionally the sudo binary.

Read More: \[Authentication Options for Oracle Fleet Patching and Provisioning Operations\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/authentication-options-for-oracle-fleet-patching-and-provisioning-operations.html)

## Oracle Fleet Patching and Provisioning Roles

Oracle Fleet Patching and Provisioning uses built-in roles to control permissions for role, client, series, image, working-copy, root-user-action, and general client operations. Composite roles such as GH\_SA, GH\_CA, and GH\_OPER combine multiple basic roles for server administrators, client administrators, and operators. Permissions determine which resources users can create, modify, provision, or delete, and client-specific user-role mappings are scoped by client cluster. Users and roles can be assigned during client creation or managed afterward with grant and revoke commands; the maproles option is deprecated beginning with Oracle Grid Infrastructure 21c.

Read More: \[Oracle Fleet Patching and Provisioning Roles\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/oracle-fleet-patching-and-provisioning-roles.html)

## Managing the Fleet Patching and Provisioning Client Password

The Fleet Patching and Provisioning Client password is stored internally and cannot be queried. To reset it, an administrator generates a new password on the server, exports updated client credentials to a file, securely transfers the file to the client cluster, updates the client with the credential data, and restarts the client daemon so the new authentication information takes effect.

Read More: \[Managing the Fleet Patching and Provisioning Client Password\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/managing-the-fleet-patching-and-provisioning-client-password.html)

## Switching Oracle FPP Server to a New Custom Certificate

Replacing or updating the Oracle Fleet Patching and Provisioning Server certificate temporarily breaks server-client communication. The procedure requires generating a PKCS#12 file, configuring and restarting the server with the new certificate, exporting updated client credentials, securely transferring them to each client, updating client certificate and server-key information, restarting the clients, and verifying connectivity with rhpctl query server. The process must be repeated for every client cluster, and custom certificates are optional on individual clients.

Read More: \[Switching Oracle FPP Server to a New Custom Certificate\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/switching-oracle-fpp-server-to-a-new-custom-certificate.html)

## Switching Oracle FPP Client to a New Custom Certificate

To replace an Oracle Fleet Patching and Provisioning Client certificate, first verify connectivity, generate a PKCS#12 certificate file, configure the client with the new certificate, and restart it. Export the server’s client credential data, securely copy it to the client, update the client’s stored server public key, restart the client, and verify communication. The procedure can be repeated for other clients, and custom certificates need not be used consistently across all clients and the server.

Read More: \[Switching Oracle FPP Client to a New Custom Certificate\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/switching-oracle-fpp-client-to-a-new-custom-certificate.html)

## Oracle Fleet Patching and Provisioning Server Auditing

The Oracle Fleet Patching and Provisioning Server audits all operations, recording their processing details and whether they succeeded or failed. Administrators can query audit records across different dimensions and manage the audit log’s contents and size.

Read More: \[Oracle Fleet Patching and Provisioning Server Auditing\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/oracle-fleet-patching-and-provisioning-server-auditing.html)

## User-Defined Actions

User-defined shell scripts can run before or after operations such as image import, working-copy management, database changes, and Grid Infrastructure or software-home updates on servers, clients, or client-less targets. Actions are stored on the server, receive operation context through named parameters, and can optionally transfer associated files to the execution target. Image types can distinguish actions for different software releases, with base-type actions running before derived image-type actions. Administrators can create, modify, associate, and remove actions, control failure behavior and execution scope, and pass custom data through the user-action parameter.

Read More: \[User-Defined Actions\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/user-defined-actions.html)

## Oracle Fleet Patching and Provisioning Notifications

Oracle Fleet Patching and Provisioning supports email subscriptions for image-series events, including image additions and removals, with separate subscriber groups for each series. Notifications can also inform working-copy owners and additional users when working copies are added to or deleted from client-less targets. Further event notifications can be implemented through user-defined actions.

Read More: \[Oracle Fleet Patching and Provisioning Notifications\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/oracle-fleet-patching-and-provisioning-notifications.html)

## Job Scheduler for Operations

The Oracle Fleet Patching and Provisioning job scheduler queues supported operations for immediate or scheduled execution, stores job metadata and logs, and supports querying, deletion, role-based authorization, and, from Grid Infrastructure 26ai, pausing and resuming jobs. Scheduling uses a timer or PAUSE value and applies the server’s time zone with ISO-8601 timestamps. Jobs receive unique identifiers and progress through states including TIMER\_RUNNING, EXECUTING, EXECUTED, UNKNOWN, TERMINATED, or PAUSED; paused jobs can be resumed after prerequisite validation.

Read More: \[Job Scheduler for Operations\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/job-scheduler-for-operations.html)

## Patching Oracle Grid Infrastructure and Oracle AI Database Using Batches

Fleet Patching and Provisioning supports rolling patching by restarting groups of cluster nodes in batches, maximizing service availability. Administrators can specify batches and advance through them with continue, skip, revert, or abort options, or allow smartmove to generate batches based on service placement and a specified service availability factor. Evaluation mode previews automatically generated batches without making changes. The same sequential batching approach applies to Oracle AI Database patching, while failures can be retried, skipped, reverted, or left for manual recovery when aborted.

Read More: \[Patching Oracle Grid Infrastructure and Oracle AI Database Using Batches\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/patching-oracle-grid-infrastructure-and-oracle-ai-database-using-batches.html)

## Combined Oracle Exadata Database Server and Grid Infrastructure Update

Combined patching integrates Exadata database-node updates with Grid Infrastructure home moves so each node requires only one database shutdown and startup sequence, reducing downtime. Administrators import an Exadata update image, deploy it to the target, and run move gihome with Exadata image, batch, ISO repository, and patch-manager parameters. Fleet Patching and Provisioning invokes patchmgr for database-node updates before Grid Infrastructure patching, can process nodes in parallel within batches, and allows operations to resume after patch-manager failures or timeouts.

Read More: \[Combined Oracle Exadata Database Server and Grid Infrastructure Update\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/updating-oracle-exadata-infrastructure/combined-oracle-exadata-database-server-and-grid-infrastructure-update.html)

## Gold Image Distribution Among Oracle Fleet Patching and Provisioning Servers

Oracle Fleet Patching and Provisioning Servers can share gold images through peer relationships and image instantiation. Administrators export and exchange server configuration files, register each server as a peer, verify the relationship, and configure replication for all images or selected images, series, or image types. Replicated images can be queried and automatic synchronization can be stopped with uninstantiate; unregistering a peer ends replication but preserves images already instantiated. Peer relationships are not transitive, and each server can maintain multiple independent peers.

Read More: \[Gold Image Distribution Among Oracle Fleet Patching and Provisioning Servers\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/gold-image-distribution-among-oracle-fleet-patching-and-provisioning-servers.html)

## Error Prevention and Automated Recovery Options

The eval option performs prerequisite checks and predicts configuration effects without changing the environment, allowing administrators to validate operations before a maintenance window. For in-flight move failures, administrators can correct the cause and rerun the command, revert to the initial state, or abort while leaving the environment partially changed for manual recovery. Post-update issues can be addressed by reversing the source and destination homes in a new move operation, subject to managed and unmanaged home requirements.

Read More: \[Error Prevention and Automated Recovery Options\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/error-prevention-and-automated-recovery-options.html)

## Fleet Patching and Provisioning Logs and Trace Files

Oracle Fleet Patching and Provisioning diagnostics rely on server logs, helper logs, Java application-server output, Grid Infrastructure and CRSD traces, and database deployment or upgrade logs. These files provide details for troubleshooting server, client, startup, shutdown, deployment, and upgrade failures. Trace File Analyzer can collect the relevant Fleet Patching and Provisioning diagnostics with the rhp option.
Read More: \[Fleet Patching and Provisioning Logs and Trace Files\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/fleet-patching-and-provisioning-postinstallation-tasks/fleet-patching-and-provisioning-logs-and-trace-files.html)


# Oracle Fleet Patching and Provisioning Use Cases

## Creating an Oracle Grid Infrastructure 26ai Deployment

This procedure provisions Oracle Grid Infrastructure 26ai on nodes without an existing Grid home and configures them as a multi-node installation. Before starting, prepare a response file containing storage, network, user, group, and node details, verify system prerequisites, and ensure standalone-cluster settings if applicable. The `rhpctl add workingcopy` command creates the working copy, runs CVU checks, and performs configuration; provisioning pauses on errors and can resume after corrections.

Read More: \[Creating an Oracle Grid Infrastructure 26ai Deployment\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/creating-an-oracle-grid-infrastructure-26ai-deployment.html)

## Provisioning an Oracle AI Database Home and Creating a Database

Fleet Patching and Provisioning provisions an Oracle AI Database 26ai home from a gold image to a specified cluster path, then creates database instances in that working copy. The `rhpctl add database` command creates an Oracle RAC database and can be repeated to create additional instances.

Read More: \[Provisioning an Oracle AI Database Home and Creating a Database\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/provisioning-an-oracle-ai-database-home-and-creating-a-database.html)

## Provisioning a Pluggable Database

A PDB can be added to an existing multitenant CDB running in a provisioned database working copy using `rhpctl addpdb database`, provided the CDB was created from a provisioned working copy. The corresponding `rhpctl deletepdb database` command removes an existing PDB from the CDB.

Read More: \[Provisioning a Pluggable Database\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/provisioning-a-pluggable-database.html)

## Upgrading to Oracle Grid Infrastructure 26ai

Fleet Patching and Provisioning upgrades clusters from Oracle Grid Infrastructure 19c or 21c to 26ai, provided source and destination groups match and a 26ai Grid image is available. First create a 26ai working copy, then run `rhpctl upgrade gihome` with the active source working copy and new destination working copy; FPP identifies and upgrades the associated cluster.

Read More: \[Upgrading to Oracle Grid Infrastructure 26ai\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/upgrading-to-oracle-grid-infrastructure-26ai.html)

## Patching Oracle Grid Infrastructure and Oracle AI Databases Simultaneously

This procedure patches Grid Infrastructure and multiple Oracle RAC database releases with minimal disruption by first provisioning patched Grid and database working copies without database instances. The `rhpctl move gihome` command then relocates the active Grid home and each database home on a target node to their patched working copies, supporting simultaneous patching of 26ai and 21c databases.

Read More: \[Patching Oracle Grid Infrastructure and Oracle AI Databases Simultaneously\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/patching-oracle-grid-infrastructure-and-oracle-ai-databases-simultaneously.html)

## Patching Oracle Data Guard Database Automatically

Oracle FPP 26ai can discover Data Guard standby databases and patch them before their primary databases through one scheduled operation. Review the Data Guard configuration, run `rhpctl move database` with `-patchdataguard YES`, and monitor the returned parent job to track the complete standby and primary patching process; individual standby jobs can also be monitored separately. Databases registered on different clients require those clients to be registered as peers.

Read More: \[Patching Oracle Data Guard Database Automatically\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/patching-oracle-data-guard-database-automatically.html)

## Patching Oracle AI Database 26ai Without Downtime

An Oracle AI Database 26ai home can be patched without database downtime by moving it from an unpatched working copy to a patched working copy with `rhpctl move database`. The procedure supports both FPP-managed homes and unmanaged homes specified by path, and also allows rollback by moving back with `-ignorewcpatches`. Optional controls preserve service placement, drain sessions, set stop behavior, and suppress `datapatch`.

Read More: \[Patching Oracle AI Database 26ai Without Downtime\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/patching-oracle-ai-database-26ai-without-downtime.html)

## Upgrading to Oracle AI Database 26ai

Fleet Patching and Provisioning upgrades databases from Oracle Database 19c or 21c to 26ai when the Grid Infrastructure release is equal to or later than the target database release. Managed homes use `rhpctl upgrade database` with source and destination working copies, while unmanaged homes use `rhpctl move database` with the source home path, destination working copy, and target node. Afterward, the database is managed by FPP, and failed upgrades can resume after corrective action.

Read More: \[Upgrading to Oracle AI Database 26ai\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/upgrading-to-oracle-ai-database-26ai.html)

## Performing Oracle Exadata Database Node Live Update

Oracle FPP supports Exadata Live Update by applying a working-copy image and ISO repository to selected database nodes with `rhpctl update exadata -dbnodes`. The workflow evaluates prerequisites, backs up the current configuration, performs the live update, and uses `rhpctl query client -exadata` to verify the client, image, software version, and live-update status.

Read More: \[Performing Oracle Exadata Database Node Live Update\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/performing-oracle-exadata-database-node-live-update.html)

## Provisioning an Oracle AI Database Using Zip Copy

ZipCopy provisions Oracle AI Database homes from software archives already accessible on shared or local storage at target hosts, avoiding transfer from the FPP Server. Import the image with `-zip` and `-location`, verify its target location, and create a working copy with `-localmount` and the archive location. The feature supports existing Grid Infrastructure homes but not new Grid home provisioning and requires shared access between the server and targets.

Read More: \[Provisioning an Oracle AI Database Using Zip Copy\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/provisioning-an-oracle-ai-database-using-zip-copy.html)

## Adding a Node to a Cluster and Scaling an Oracle RAC Database to the Node

FPP can expand a two-node Oracle Grid Infrastructure cluster and scale an administrator-managed RAC database to the added node. Run `rhpctl addnode gihome` to add the node and its VIP to the active Grid working copy, then run `rhpctl addnode database` to extend the database home and create the database instance on the new node.

Read More: \[Adding a Node to a Cluster and Scaling an Oracle RAC Database to the Node\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/adding-a-node-to-a-cluster-and-scaling-an-oracle-rac-database-to-the-node.html)

## Adding Gold Images for Fleet Patching and Provisioning

Gold images are created from Oracle homes located on the FPP Server, an FPP Client, or a reachable rhpclient-less target and stored on the FPP Server for later provisioning. Use `rhpctl import image` with the home path and appropriate image type, such as database, Grid Infrastructure, or generic software. Images are templates and must be used to create working copies rather than serving directly as software homes.

Read More: \[Adding Gold Images for Fleet Patching and Provisioning\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/adding-gold-images-for-fleet-patching-and-provisioning.html)

## User Actions for Common Fleet Patching and Provisioning Tasks

FPP user actions automate software installation, configuration, and custom scripts during provisioning. A typical workflow registers an action script, associates it with a custom image type, imports a gold image, and provisions a working copy with configuration data. Multiple scripts can be packaged into an archive and invoked through a wrapper action, allowing pre- or post-operation execution across selected nodes.
Read More: \[User Actions for Common Fleet Patching and Provisioning Tasks\](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/oracle-fleet-patching-and-provisioning-use-cases/user-actions-for-common-fleet-patching-and-provisioning-tasks.html)


# RHPCTL Command Reference

## RHPCTL Overview

RHPCTL is the command-line utility for administering Oracle Fleet Patching and Provisioning Servers, Clients, images, roles, sites, image series, and working copies. Commands follow the `rhpctl command object [parameters]` structure, where verbs specify actions, objects identify managed resources, and keyword-value parameters refine execution.

Read More: [RHPCTL Overview](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/rhpctl-overview.html)

## Using RHPCTL Help

RHPCTL provides context-sensitive help for discovering command usage, syntax, and parameters. Use `rhpctl -help` to list all commands, or `rhpctl command object -help` to display detailed information for a specific command and object.

Read More: [Using RHPCTL Help](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/using-rhpctl-help.html)

## archive Commands

The archive commands manage the lifecycle of Oracle Fleet Patching and Provisioning gold images: `rhpctl archive image -image image_name` archives an image that has no associated working copy, while `rhpctl unarchive image -image image_name` restores an archived image for use.

Read More: [archive Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/archive-commands.html)

## audit Commands

Audit commands manage Fleet Patching and Provisioning audit records. Administrators can delete all records or those up to a specified date, change the maximum number of stored records, and query records using filters such as operation, entity, user, client, date range, record position, record ID, or configuration details.

Read More: [audit Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/audit-commands.html)

## backup and restore Commands

Backup and restore commands protect and recover the Oracle Fleet Patching and Provisioning Server. `rhpctl backup server -path backup_path` creates a full server backup in a writable directory, while `rhpctl restore server -backup backup_location` restores or relocates a server from the specified backup.

Read More: [backup and restore Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/backup-and-restore-commands.html)

## client Commands

Client commands add, authorize, disable, discover, export, modify, query, update, verify, and delete Fleet Patching and Provisioning Clients. They support remote-node authentication, role mappings, response-file generation and validation for Oracle Clusterware deployment, client data export, enablement and credential changes, image updates, detailed configuration queries, and controlled removal; most administrative operations run from the Fleet Patching and Provisioning Server, and clients require Oracle Grid Infrastructure 12.2 or later.

Read More: [client Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/client-commands.html)

## credentials Commands

Credential commands add or remove remote-access credentials in the Oracle Cluster Registry. `rhpctl add credentials` stores either root or sudo-based access under a credential name for reuse by other commands, while `rhpctl delete credentials` removes the specified credential.

Read More: [credentials Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/credentials-commands.html)

## database Commands

Database commands provision, modify, move, upgrade, query, and remove Oracle databases and pluggable databases associated with Fleet Patching and Provisioning working copies. They support RAC, RAC One Node, single-instance, multitenant CDB/PDB operations, administrator-managed RAC node changes, rolling and nonrolling database moves, scheduling, evaluation, authentication methods, patch and datapatch controls, service draining, recovery actions, and zero-downtime upgrades; the deprecated ZDU command uses GoldenGate and cloned storage to upgrade RAC and RAC One Node databases with minimal interruption.

Read More: [database Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/database-commands.html)

## datapatch Commands

The datapatch command applies SQL patches to databases associated with a specified working copy. It can target selected databases or exclude named databases, operate on remote targets with root, sudo, credential, or plugin authentication, evaluate planned node batches without execution, and run immediately or through scheduled jobs.

Read More: [datapatch Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/datapatch-commands.html)

## exadata Commands

The Exadata command patches Oracle Exadata database nodes, storage cells, InfiniBand switches, or RoCE switches. It supports images, patch manager and ISO repositories, backups, rollbacks, downgrades, live-update scopes, node batching with continuation or abort controls, email notifications, scheduled execution, remote clients or servers, and evaluation mode; its documented primary use is database-node patching.

Read More: [exadata Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/exadata-commands.html)

## gihome Commands

These commands manage Oracle Grid Infrastructure homes and nodes: `rhpctl addnode gihome` provisions Grid Infrastructure on new nodes, `deletenode gihome` removes it, `move gihome` relocates or transparently upgrades the Grid home with rolling, batching, patching, database, scheduling, and recovery controls, and `upgrade gihome` upgrades from a working copy or unmanaged home to a destination working copy with evaluation, batching, rollback, and authentication options.

Read More: [gihome Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/gihome-commands.html)

## home Commands

The `home` command family supports Oracle FPP Local Mode home deployment through `rhpctl deploy home`, which provisions Grid Infrastructure or Oracle AI Database software from a gold-image ZIP to a specified target path, optionally using a source home and bypassing prerequisite checks.

Read More: [home Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/home-commands.html)

## image Commands

These commands manage FPP gold images throughout their lifecycle: images can be created from working copies, imported, registered, deployed, copied from peer servers, promoted between states, modified, queried, deleted or archived, and granted or revoked for users and roles; Local Mode also supports downloading patched images recommended by Oracle Update Advisor and stopping replication from peer servers.

Read More: [image Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/image-commands.html)

## imagetype Commands

These commands administer image types and their associated user actions. Administrators can create custom types from supported base types, modify or delete custom definitions, grant or revoke access for users and roles, and query image-type configuration locally or across matching FPP servers; built-in image types cannot be deleted.

Read More: [imagetype Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/imagetype-commands.html)

## job Commands

The job commands control scheduled FPP operations. `rhpctl delete job` removes one scheduled job or all jobs, optionally forcibly, while `rhpctl query job` reports job details, status, execution information, evaluation or migration jobs, and results filtered by identifier, client, user, or time; both commands run on the FPP Server.

Read More: [job Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/job-commands.html)

## osconfig Commands

These commands manage operating-system configuration backups for client clusters: configurations can be collected, compared by backup identifiers, enabled with schedules, frequencies, retention counts, and immediate collection, disabled with optional cleanup, and queried for historical collection details and storage information.

Read More: [osconfig Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/osconfig-commands.html)

## patch Commands

The patch commands evaluate, apply, roll back, and monitor one-off or advisor-driven patches. Working copies can be patched in place from images or staged patch locations, including online database patches and optional datapatch execution; rollback supports selected patch IDs, while evaluation reports health and recommendations and can generate patched images in Local Mode, and query operations track Oracle Update Advisor requests.

Read More: [patch Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/patch-commands.html)

## peerserver Commands

The `rhpctl query peerserver` command displays information about a registered peer Fleet Patching and Provisioning Server and can optionally show that server’s image policy.

Read More: [peerserver Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/peerserver-commands.html)

## updateadvisor Commands

The `rhpctl manage updateadvisor` command registers one SSO user per FPP Server for Oracle Update Advisor access, with optional proxy and endpoint settings, or unregisters the currently registered user.

Read More: [updateadvisor Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/updateadvisor-commands.html)

## role Commands

Role commands administer FPP authorization: roles can be created with included permissions, deleted when not built in, granted to users, client users, or other roles, queried for associated roles and users, and revoked through direct assignments or role-to-user mappings; administration is performed on the FPP Server by appropriately privileged users.

Read More: [role Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/role-commands.html)

## series Commands

These commands manage ordered image series. Administrators can create and delete series, insert or remove images, query series locally or across peer servers, and subscribe or unsubscribe users, optionally associated with client clusters; deleting a series does not delete its images, while forced deletion can remove a series that still contains images.

Read More: [series Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/series-commands.html)

## server Commands

Server commands manage FPP Server relationships and repository data: configuration can be queried, repository information exported for a peer, a peer FPP Server registered using a data file and remote authentication, and an existing peer unregistered, optionally with force.

Read More: [server Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/server-commands.html)

## tag Commands

Tag commands provide metadata management for FPP entities. Tags can be created, queried, modified, deleted with optional force, and assigned or removed from database or site targets using comma-separated tag lists and target identifiers.

Read More: [tag Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/tag-commands.html)

## user Commands

User commands manage FPP user email registration and repository membership. Administrators can register, modify, or unregister RFC 822 email addresses for users locally or on client clusters, and delete users subject to ownership constraints; owned working copies prevent deletion, while image and series ownership is reassigned to the internal user when applicable.

Read More: [user Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/user-commands.html)

## useraction Commands

The `useraction` commands manage custom actions associated with Fleet Patching and Provisioning operations. Use `rhpctl add useraction` to define an action script, optional action file, execution timing, operation type, phase, error behavior, node scope, and execution context; use `delete` to remove a configuration, `modify` to update it, and `query` to display configured actions by name, image type, or operation type. User actions may run before, after, or during evaluation, and some options, such as `-runninginstance`, are restricted to specific operation types.

Read More: [useraction Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/useraction-commands.html)

## workingcopy Commands

The `workingcopy` commands create and manage software or database working copies across client clusters and target nodes. `add workingcopy` provisions a copy from an image or series with options for storage, Oracle homes, databases, Grid Infrastructure, cluster nodes, authentication, scheduling, notifications, patch comparison, and read-only deployment; `addnode` extends a RAC database to additional nodes; `delete` removes a working copy or only its metadata, subject to active database restrictions; `query` displays configuration, drift, image, client, or metadata details; and `register` records an existing working copy in the FPP repository. Commands support evaluation, scheduling, user-action data, remote access, software-only provisioning, and site-specific configuration.
Read More: [workingcopy Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/rhpctl-command-reference/workingcopy-commands.html)