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.

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.

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.

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.

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