Automating Oracle Deployments with Fleet Patching & Provisioning (FPP)

Legacy “Software Packager” workflows were designed for distributing installers to many desktops. In the cloud-era, Oracle’s Fleet Patching & Provisioning (FPP) replaces that approach with centralized, image-based automation for database and grid homes. FPP standardizes software across large estates, minimizes outage windows via out-of-place patching, and lets you operate at fleet scale.

Core Concepts

• FPP Server: Central service (in Grid Infrastructure) that owns the image repository, orchestration, and policies.
• Clients: Target nodes (DB/Grid homes) registered to the FPP Server; they receive images and execute workflows.
• Gold Images: Immutable, versioned homes (DB or GI) built from a known-good reference with required patches.
• Working Copies: Materialized deployments of a gold image on a client; used as the new target home for switchovers.
• Out-of-Place Patching: Instead of modifying the live home, deploy a new patched home, stop services, switch, and start.

Why FPP Over Legacy Methods?

• Consistency: One image drives hundreds of homes; eliminates configuration drift.
• Speed & Safety: Most work occurs ahead of time. The cutover is a brief stop/switch/start.
• Scale: Fan out to many targets concurrently; track status centrally.
• Governance: Versioned images, approvals, and rollbacks integrate with change control.

Prerequisites & Topology (Sanity Check)

• FPP Server provisioned (in GI), reachable by targets; repository storage sized for images.
• Targets (clients) registered and authorized; required SSH/IAM policies in place.
• Reference environment(s) to compose baseline images; repeatable method to refresh/patch and re-image.

Golden Path Workflow

1. Create/Import a Gold Image from a patched reference home.
2. Subscribe target homes (DB/GI) to a specific image/version.
3. Deploy Working Copies to clients (pre-stage new homes).
4. Switch databases from old home to the new working copy (brief outage).
5. Verify services, datapatch status, and performance; decommission old homes after sign-off.

Command-Line Examples (rhpctl)

1) Create or Import a Gold Image

# Import a prepared database home as a gold image
rhpctl import -image DB23_1 -path /u01/app/oracle/product/23.1.0/dbhome_1

# List images
rhpctl query image

2) Provision a Working Copy

# Local working copy on a client host
rhpctl add workingcopy \
  -workingcopy DB_HOME_231 \
  -image DB23_1 \
  -storagetype LOCAL \
  -oraclebase /u01/app/oracle

# Client-directed working copy (explicit path)
rhpctl add workingcopy \
  -image DB23_1 \
  -path /u01/app/oracle/product/23.1.0/dbhome_23c \
  -workingcopy DB_HOME_23c \
  -client client_042 \
  -oraclebase /u01/app/oracle

3) Switch Databases to the New Home

# Stop → switch → start is orchestrated by FPP
# Example flow (syntax may vary by environment/policy)
rhpctl move database \
  -dbname PROD \
  -targetworkingcopy DB_HOME_23c

4) Post-Switch Validation

# Confirm datapatch status, components, and registry
$ORACLE_HOME/OPatch/datapatch -verbose

# Confirm image and working copy status
rhpctl query workingcopy

Enterprise Manager (Optional)

If you prefer a GUI + API approach, Enterprise Manager Fleet Maintenance can create and manage software images and invoke FPP actions. Automations can also be scripted via emcli.

# Example (illustrative)
emcli db_software_maintenance \
  -createSoftwareImage \
  -input_file="data:/home/user/image_input.json"

Automated Patching Modes

• Rolling: GI nodes patched sequentially for service continuity.
• Nonrolling: All nodes patched in parallel (more disruptive, faster).
• Batch: Coordinate GI and DB home updates together.
• Near-zero downtime: Combine FPP with Data Guard/GoldenGate for database cutover with minimal interruption.

Policy, Governance, and Drift Control

• Keep gold images immutable; introduce changes via new versions (e.g., DB23_2, DB23_3).
• Store image manifests and change logs in Git; tag releases that pass UAT.
• Use subscriptions to map fleets to image versions; promote from DEV → TEST → PROD.
• Continuously audit homes for drift; only remediate by re-baselining to the approved image.

Migrating from “Software Packager” to FPP

• Stop shipping installers; start shipping images.
• Replace ad-hoc scripts with standardized rhpctl or EM workflows.
• Measure success via reduced outage, fewer post-patch defects, and converged home inventories.

Next lesson: Module summary & runbook pointers, tying provisioning (Lesson 2), parameters (Lesson 3), DBCA/OCI (Lesson 4), upgrades (Lesson 5), and FPP (Lesson 6) into a single operational playbook.