Oracle RAC 19c rolling Release Update (opatchauto)

Applies a quarterly GI Release Update to a running 2–8 node RAC 19c cluster in rolling mode, without downtime: OPatch update, conflict check with opatchauto analyze, OCR backup and fallback point, node-by-node apply with services relocated, datapatch completed on a single node, verification and rollback if needed. For single instance and Oracle Restart use the "Applying an Oracle Database 19c Release Update (RU)" guide; the OJVM RU is not rolling and needs a separate outage.

Topology: Existing 2–8 node RAC 19c

Before you start

• The RU README has been read: minimum OPatch version, known issues, prerequisite one-offs, the separate OJVM patch (the OJVM RU is not rolling and needs a separate outage). "Oracle Database 19c Important Recommended One-off Patches" (Doc ID 555.1) and the RU download guide (Doc ID 2118136.2) on My Oracle Support have been checked for this RU.
• Every node has … and p6880880_190000_Linux-x86-64.zip (latest OPatch) under …; the files have been verified against the SHA-256 values on MOS.
• The file system holding the GI and DB homes has at least 20 GB free (check the value in the README), and /tmp has at least 1 GB free. …… has room for the home backups.…
• The cluster is healthy: CRS online on all nodes, no resources left OFFLINE, all instances open. While one node is down during patching, the remaining nodes have the capacity to carry the full workload.
• Application services are defined so that on every node they can fail over to another instance (preferred/available or uniform), and applications connect through SCAN + service name (with FAN/AC, sessions move without interruption).
• The database has a current RMAN backup and its archived logs; an OCR backup has been taken. The maintenance window is approved; a blackout is set in Enterprise Manager.
• No other opatch/opatchauto operation is running; there are no lock files in the homes.
• If the database has a Data Guard standby, the standby cluster (or server) is patched first (Standby-First, MOS 1265700.1); the primary is patched afterwards with this guide and datapatch runs on the primary only.

Phases of the guide

• Pre-checks — Record the current patch level (Clusterware) · List the patches in the homes (…) · Record the SQL patch history and invalid objects
• Preparation: RU, OPatch and analysis — Extract the RU (…) · Update OPatch in the GI home (…) · Update OPatch in the DB home (…) · Run the conflict and prerequisite analysis (…)
• Backup and fallback point — Take a manual OCR backup · Create a guaranteed restore point · Back up the GI and DB homes (…)
• Verification and completion — Make sure the PDBs are open · Run datapatch on one node only · Verify the SQL patch registry · Recompile invalid objects (if needed) · Verify the cluster patch state · Return services to their preferred placement …
• Rollback (only if needed) — Rollback: run opatchauto rollback (…) · Rollback: run datapatch (single node) · Rollback: verify the result · Last resort: flash the database back to the restore point