Step-by-Step Procedure for Applying Oracle Database 19c/23c Release Updates (RU) & The Top 5 Patching Mistakes DBAs Make

Executive Summary: Modern Oracle Patching Architecture

Beginning with Oracle Database 18c and 19c, Oracle introduced Quarterly Release Updates (RU) and replaced legacy CPU patching with a two-tier patching workflow:

1. Binary Patching: Updating physical binaries in $ORACLE_HOME using opatch or opatchauto.
2. SQL Dictionary Patching: Updating in-database package bodies, views, and catalog objects using datapatch.

Failing to complete both phases or skipping pre-checks leads to dictionary corruption, invalid SYS packages, and database instability.

---

5-Step Official Oracle 19c/23c Patching Procedure

---

Step 1: Download & Update the OPatch Utility

Before applying any Release Update, verify and update the OPatch utility in $ORACLE_HOME/OPatch to the minimum version required by the patch readme (e.g. 12.2.0.1.40 or higher):

# Verify current OPatch version
$ORACLE_HOME/OPatch/opatch version

# Upgrade OPatch if version is outdated
cd $ORACLE_HOME
mv OPatch OPatch_old
unzip /u01/patches/p6880880_190000_Linux-x86-64.zip -d $ORACLE_HOME

---

Step 2: Perform Pre-Patch Conflict & Prerequisite Analysis

Run pre-checks to detect filesystem permission issues, space constraints, or conflicts with one-off interim patches:

# For Oracle Grid Infrastructure / RAC (as root):
/u01/app/oracle/product/19.0.0/dbhome_1/OPatch/opatchauto apply /u01/patches/36800000 -analyze

# For Single Instance Database (as oracle):
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstCurrentWithInstalledPayLoad -ph /u01/patches/36800000

---

Step 3: Audit & Clean Pre-Patch Invalid Objects

Check for broken SYS or SYSTEM objects prior to binary application:

-- Query Pre-Patch Invalid Object Count
SELECT owner, object_name, object_type 
FROM dba_objects 
WHERE status = 'INVALID' AND owner IN ('SYS', 'SYSTEM');

-- Compile invalid objects if any exist
@?/rdbms/admin/utlrp.sql

---

Step 4: Apply Binary Release Update

Option A: Oracle RAC / Grid Infrastructure (Rolling Zero Downtime as root)

# OPatchAuto handles GI and Database Home binary application automatically node-by-node
/u01/app/19.0.0/grid/OPatch/opatchauto apply /u01/patches/36800000

Option B: Standalone Single Instance (as oracle user with DB shut down)

# Shutdown Listener and Database
lsnrctl stop
sqlplus / as sysdba <<< "SHUTDOWN IMMEDIATE;"

# Apply Patch
cd /u01/patches/36800000/19000000
$ORACLE_HOME/OPatch/opatch apply

---

Step 5: Execute Datapatch (Mandatory Post-Install Step)

After binary installation, start the database instance and run datapatch to apply SQL script updates to the database dictionary:

# Startup Database Instance
sqlplus / as sysdba <<< "STARTUP;"

# Run Datapatch in Verbose Mode
cd $ORACLE_HOME/OPatch
./datapatch -verbose

# Compile Remaining Invalid Objects
sqlplus / as sysdba <<< "@?/rdbms/admin/utlrp.sql"

---

💥 Top 5 Mistakes DBAs Make When Patching Oracle 19c/23c

❌ Mistake 1: Forgetting to Run datapatch After Binary Installation

• The Error: DBAs apply the OPatch binary patch, start the database, and assume patching is complete without executing ./datapatch -verbose.
• The Consequence: Binary files on disk are version 19.24, but the in-database SQL catalog remains at version 19.20. SYS packages fail with runtime compilation errors (ORA-00600 or ORA-04045).

❌ Mistake 2: Using an Outdated OPatch Utility Version

• The Error: Attempting to apply a 2026 Release Update using a 2022 OPatch binary.
• The Consequence: Triggers cryptic OPatch failed with error code 73 or incomplete shared library relinking (ins_rdbms.mk).

❌ Mistake 3: Ignoring Pre-Existing Invalid Objects Prior to Patching

• The Error: Applying a Release Update while SYS or SYSTEM objects are already in an INVALID state.
• The Consequence: datapatch fails midway through execution, leaving dba_registry_sqlpatch in a state of WITH ERRORS and locking database dictionary views.

❌ Mistake 4: Non-Rolling Patching on Oracle RAC Clusters

• The Error: Manually shutting down all RAC cluster nodes simultaneously instead of using opatchauto rolling mode.
• The Consequence: Causes complete client application outage when zero-downtime rolling patching was available.

❌ Mistake 5: Failing to Backup $ORACLE_HOME and spfile Before Patching

• The Error: Proceeding with binary application without creating a tarball backup of $ORACLE_HOME.
• The Consequence: If relinking fails or a power loss corrupts shared libraries, rollback becomes impossible without a full OS restore.

---

🔍 Check Your Database Environment Now (Diagnostic CTA)

Run the following SQL query right now to verify if previous Release Update datapatch runs completed successfully or if your database catalog is in a corrupted WITH ERRORS state:

-- Diagnostic: Verify Datapatch Execution History & Status
SELECT 
    patch_id,
    patch_uid,
    version,
    action,
    status,
    action_time,
    description
FROM dba_registry_sqlpatch
ORDER BY action_time DESC;

Expected Results:

• STATUS = 'SUCCESS': Your SQL dictionary patch level is healthy and matches your binary install.
• 🚨 STATUS = 'WITH ERRORS' or missing recent patch entries: Datapatch failed or was never executed. You must re-run $ORACLE_HOME/OPatch/datapatch -verbose immediately.

---

Need assistance executing complex Oracle 19c/23c Release Update patching or resolving failed datapatch states across your enterprise databases? Download our RMAN & Patching Runbook Package or Schedule an Emergency Database Health Audit.