Applying an Oracle Database 19c Release Update (RU)

Applies a quarterly Release Update to a single-instance or Oracle Restart (Grid Infrastructure + ASM) 19c database: OPatch update, conflict and space prechecks, ORACLE_HOME backup and guaranteed restore point, opatch apply (opatchauto for Oracle Restart), optional OJVM RU, datapatch, utlrp and verification. Includes the out-of-place path that shortens the outage (install into a new home and switch over) and rollback steps for every path. If RAC is selected, it points to the RAC guide for node-by-node rolling apply.

Topology: 1 server (single instance or Oracle Restart); for RAC, the rolling patch guide

Before you start

• Patch files under …: …GI RU ……DB RU ………, OJVM RU ……, OPatch …… and the base install file for the new home, LINUX.X64_193000_db_home.zip…. Check the patch number on MOS and read the RU README end to end (the minimum OPatch version, known issues and extra steps are in the README).
• The versions of the one-off patches recommended in MOS 555.1 that match the new RU are downloaded; it is known whether the one-offs in the current home conflict with the new RU (a conflicting one-off needs a new version built on top of the RU).
• The current patch level and database state are recorded; all components are VALID.
• There is free space of at least 15 GB on the file system holding ORACLE_HOME (OPatch keeps the old files in .patch_storage), as much as the home size in ……, and at least 15 GB for the new home….
• For the restore point, the database is in ARCHIVELOG mode and the FRA has enough free space (for the flashback logs generated during the patch).
• There is a successful, tested RMAN backup from the last 24 hours.
• The maintenance window is approved; application teams know about the outage; monitoring (EM/agent) is in blackout; scheduled jobs (cron, DBMS_SCHEDULER) are stopped.
• If possible, a snapshot of the server (VM) has been taken.
• If the database has a Data Guard standby, the patch order is planned: the standby's home is patched first (Standby-First, MOS 1265700.1), the primary is patched later and datapatch runs only on the primary. Skip this item if there is no standby.
• The cluster is healthy and the instances are open on all nodes; the detailed prerequisites for RAC patching are in the Oracle RAC 19c rolling Release Update guide.
• Standby-First conditions (MOS 1265700.1): the RU README states 'Data Guard Standby-First Installable' (Release Updates qualify; for one-offs check the README separately)…; the 19c OJVM RU is not unconditionally Standby-First (see the note below)…; the patch difference between primary and standby is kept only for the (short) transition period; datapatch runs once, only on the primary, after all standbys and the primary have been patched.… All standbys of this primary have the new RU binaries installed and the standbys keep applying.…

Phases of the guide

• RAC: verify the environment and move to the rolling patch guide — Verify the cluster and nodes · Apply the RAC rolling patch guide
• Prechecks — Check the current patch level (DB home) · Check the current patch level (Grid home) · Check the database state and SQL patch history · Check the standby's role and apply status (Data Guard standby) · Check the Data Guard status (primary) · Verify that the new RU is installed on the standbys …
• Backup and fallback point — Check the RMAN backups · Stop Redo Apply (Data Guard standby) · Create a guaranteed restore point · Create a guaranteed restore point (standby)
• Apply: in-place (opatch apply) — Stop the database and listener · Back up ORACLE_HOME and the inventory · Apply the RU (opatch apply) · Apply the OJVM RU · Start the listener and database · Start the listener and the standby in MOUNT, turn apply on
• Apply: in-place (Oracle Restart, opatchauto) — Stop Oracle Restart (for the backup) · Back up the Grid home, DB home and inventory · Start Oracle Restart · Apply the GI RU (opatchauto) · Apply the OJVM RU to the DB home · Start Redo Apply (Data Guard standby)
• Apply: out-of-place (new home) — Create the new home directory · Extract the base software and update OPatch · Prepare the response file for the new home · Install the new home with the RU · Run root.sh (new home) · Compare the patches in the old and new homes …
• SQL-level patch (datapatch) — Run datapatch · Recompile invalid objects (utlrp) · Do not run datapatch on the standby · Verify that the SQL changes reach the standbys
• Verification — Verify the binary patch level · Verify the binary patch level (Grid home) · Verify the SQL patch registry and objects · Verify on the standby that apply continues on the new binaries · Check the alert log · Run the application tests …
• Wrap-up — Drop the restore point · Drop the restore point (standby) · Clean up
• Rollback (only if needed) — Stop the database and listener · Roll back the patches (opatch rollback) · Roll back the patches (opatchauto rollback) · Switch back to the old home · Start the standby in MOUNT with the old binaries and start apply · Start and roll back the SQL patches (datapatch) …