Oracle Database 19c July 2026 RU Patching – Upgrade from 19.31 to 19.32 on Linux

الحمد لله — This post documents a real Oracle Database 19c patching activity on a Linux x86-64 environment, progressing from 19.31 to 19.32 using the July 2026 Combo Patch. The activity included precheck validation, binary patching, datapatch execution, and post-patch verification with actual command outputs.

Introduction

This article documents the steps followed to patch an Oracle Database 19c environment from 19.31 to 19.32 using the July 2026 Database and OJVM Release Update Combo Patch on Linux x86-64.

The patches applied were:

Patch 39618649
Combo of OJVM Component Release Update 19.32.0.0.260721
+ Database Jul 2026 Release Update 19.32.0.0.260721

Component patches:
39472050 - Database Release Update 19.32.0.0.260721
39222882 - Oracle JavaVM Component Release Update 19.32.0.0.260721

Pre-Patching Validation

1. Verify Current Database Patch Level

First, verify the current patches installed in the Oracle Home:

$ $ORACLE_HOME/OPatch/opatch lspatches

The environment was running the following baseline before July patching:

38906621;OJVM RELEASE UPDATE: 19.31.0.0.260421
39034528;Database Release Update : 19.31.0.0.260421
29585399;OCW RELEASE UPDATE 19.3.0.0.0

Patching objective:

• Database RU: 19.31 → 19.32 (39034528 → 39472050)
• OJVM RU: 19.31 → 19.32 (38906621 → 39222882)

6. Run DB RU Conflict Check

Before applying the Database RU, validate for conflicting one-off patches:

$ cd 39618649/39472050
$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

✓ No conflicting one-off patch was identified for the DB RU 39472050.

7. Run OJVM RU Conflict Check

Perform the same validation for the OJVM RU:

$ cd 39618649/39222882
$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

✓ No conflicting one-off patch was identified for the OJVM RU 39222882.

Post-Patching Results

OPatch Inventory Verification

$ $ORACLE_HOME/OPatch/opatch lspatches

39222882;OJVM RELEASE UPDATE: 19.32.0.0.260721
39472050;Database Release Update : 19.32.0.0.260721
29585399;OCW RELEASE UPDATE 19.3.0.0.0

OPatch succeeded.

Patch progression:

• OJVM RU: 38906621 (19.31) → 39222882 (19.32) ✓
• Database RU: 39034528 (19.31) → 39472050 (19.32) ✓
• OCW: 29585399 (unchanged) ✓

Component Registry Status

All major database components are VALID after patching:

CATALOG         VALID
CATEGORY        VALID
CATJAVA         VALID
CATOJAVA        VALID
JAVAVM          VALID
XML             VALID
XDB             VALID

Database and PDB Status

SQL> select name, open_mode, database_role from v$database;

NAME            OPEN_MODE       DATABASE_ROLE
----------      -----------     ----------------
PRODDB          READ WRITE      PRIMARY

SQL> show pdbs;

    CON_ID CON_NAME                 OPEN_MODE  RESTRICTED
---------- ---------------------- ---------- ----------
         2 PDB$SEED                 READ ONLY  NO
         3 APPPDB                   READ WRITE NO
         4 ARCHPDB                  READ WRITE NO

✓ Database and all PDBs are open and operational.

SQL Patch Registry

Both 19.32 patches applied successfully to CDB and APPPDB PDB:

PATCH_ID      ACTION     STATUS          DESCRIPTION
-----------   ---------- --------------- ----------------------------------
39222882      APPLY      SUCCESS         OJVM RU 19.32.0.0.260721
39472050      APPLY      SUCCESS         Database RU 19.32.0.0.260721

Note: During the 19.32 OJVM update, the previous 19.31 OJVM patch (38906621) may be recorded as ROLLBACK SUCCESS, followed by successful application of OJVM RU 39222882. This is normal and expected during the RU transition — it is not an indication of a patching failure.

Invalid Objects Validation

Post-patch invalid objects count: 83 (unchanged from pre-patch baseline)

✓ Invalid object count matches pre-patch baseline. No new invalids introduced by 19.32 RU.

oradism Permissions Restored

$ ls -l $ORACLE_HOME/bin/oradism
-rwsr-x---. 1 root oinstall 147848 May  5 12:25 /u01/app/oracle/product/19c/db_1/bin/oradism

✓ Permissions correctly restored to original state (root:oinstall 4750).

Rollback Plan

Important: Before executing any rollback, always:

• Verify the exact version from the patch component README
• Follow the documented rollback sequence from the README
• Test in a non-production environment first
• Obtain explicit approval from your database administration team or management

If the 19.32 RU must be rolled back, the procedure generally follows this sequence (consult the specific README for patches 39472050 and 39222882 for the authoritative step-by-step guidance):

1. Shut down the database and listener
2. Revert the OJVM RU first, then the Database RU (reverse order of application)
3. Start the database in restricted mode to verify compatibility
4. Run datapatch to revert SQL patches: ./datapatch -verbose
5. Verify patch registry and OPatch inventory reflect the reverted state
6. Open the database normally and run post-revert health checks

Always retain a clean, tested backup of the Oracle Home taken immediately before patching. This allows for rapid restoration if rollback becomes necessary.

Key Takeaways

A reliable Oracle Database RU patching activity is more than running opatch apply twice. A structured approach includes:

• Capture existing state: Patch inventory, SQL patch registry, invalid objects, database role, PDB status, and oradism permissions before making any changes.
• Validate prerequisites: Run conflict checks on both component patches and ensure OPatch is at the recommended version.
• Follow the documented sequence: Binary patches in the correct order, then startup, then datapatch.
• Verify at each step: Check OPatch inventory after binary patching, verify component registry after startup, and confirm datapatch success via the SQL registry.
• Compare against baseline: Invalid objects, registry status, and listener configuration should match pre-patch evidence.
• Plan for rollback: Maintain a clean backup and understand the documented rollback procedure from the official patch README before starting.

Oracle Database 19c was successfully upgraded from the 19.31 RU level to the July 2026 19.32 RU level, including OJVM, with successful binary patching, SQL patching, and post-patch health validation.