Oracle EBS Database Patching on Linux x86-64: Applying CPU (DB RU) + OJVM (Oct 2025) Like a Pro

If you manage an Oracle E-Business Suite (EBS) environment, one thing is non-negotiable: quarterly security patching. Oracle releases Critical Patch Updates (CPU) every quarter, and for the Database tier these typically arrive as Release Updates (RU). Along with the RU, Oracle also delivers OJVM (Oracle JavaVM) patches which address Java-related vulnerabilities and database JVM fixes.

In this post, I’m documenting a practical, DBA-friendly approach to applying Oct 2025 CPU patches for Oracle Database 19c on Linux x86-64 for an EBS system—keeping it simple, safe, and production-ready.

1) What we are patching and why

CPU / DB RU (Release Update)

The Database RU is Oracle’s quarterly cumulative patch that includes:

Security fixes (CVE fixes)
Critical defect fixes
Stability improvements

OJVM Patch

OJVM patches fix vulnerabilities and issues related to the Java VM inside the database. In many environments, DB RU and OJVM are applied together as part of the quarterly patch cycle.

2) Key patches for Oct 2025 (Oracle Database 19c)

From Oracle’s Patch Availability Document (Oct 2025 CPU PAD – DB-only), the main patch paths for 19c are:

Option A: Combo Patch (DB RU + OJVM together)

Combo RU + OJVM 19.29.0.0.251021 – Patch 38273545

This is often the easiest path because RU and OJVM are packaged together.

Option B: Apply DB RU and OJVM separately

DB RU 19.29.0.0.251021 – Patch 38291812
OJVM RU 19.29.0.0.251021 – Patch 38194382

This approach is common when DB RU is already applied and OJVM is pending, your change window is split, or you have sequencing constraints.

Optional but commonly required in many enterprises

OPatch requirement: OPatch 12.2.0.1.48+
JDK patch (if mandated): JDK8u471 Patch 38245243

3) My patching mindset for EBS systems

EBS is not just a database; it’s an application ecosystem. Even if we are patching only the Database home, the discipline remains the same:

Do conflict checks (avoid surprises)
Have a rollback plan
Take a reliable backup
Run datapatch cleanly
Validate in DBA_REGISTRY_SQLPATCH
Do a basic EBS smoke test (login + concurrent manager, if applicable)

4) Pre-checks before you touch anything

Check current DB & patch level

select * from v$version;

select patch_id, patch_type, action, status,
       to_char(action_time,'DD-MON-YYYY HH24:MI') action_time
from dba_registry_sqlpatch
order by action_time desc;

Check OPatch version

$ORACLE_HOME/OPatch/opatch version

Run conflict check (recommended)

$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /path/to/unzipped_patch

Backup (minimum expectation)

RMAN backup / snapshot / cold backup as per your org standards
Backup inventory metadata if required

5) Patching Steps (DB RU + OJVM) — the clean runbook

Below is the cleanest standard process for most EBS environments.

Method 1: Combo Patch (DB RU + OJVM together)

Patch: 38273545

Step 1 — Stage the patch

mkdir -p /u01/stage/CPU_OCT2025_19c
cd /u01/stage/CPU_OCT2025_19c
unzip p38273545_190000_Linux-x86-64.zip

Step 2 — Shutdown the database

sqlplus / as sysdba <<EOF
shutdown immediate;
exit;
EOF

Step 3 — Apply patch using OPatch

cd /u01/stage/CPU_OCT2025_19c/<patch_dir>
$ORACLE_HOME/OPatch/opatch apply

Step 4 — Startup database

sqlplus / as sysdba <<EOF
startup;
exit;
EOF

Step 5 — Run datapatch

cd $ORACLE_HOME/OPatch
./datapatch -verbose

Step 6 — Validate success

select patch_id, patch_type, action, status,
       to_char(action_time,'DD-MON-YYYY HH24:MI') action_time
from dba_registry_sqlpatch
order by action_time desc;

Method 2: Apply DB RU and OJVM separately

Use this method if you are applying:

DB RU: 38291812
OJVM RU: 38194382

Phase A — Apply DB RU

Shutdown DB
OPatch apply DB RU
Startup DB
Run datapatch

Phase B — Apply OJVM RU

Shutdown DB
OPatch apply OJVM
Startup DB
Run datapatch again

Why datapatch twice?

Because each patch updates SQL components differently, and Oracle expects SQL patch registration after each change.

6) Post-patching validation checklist (what I always verify)

OPatch inventory

$ORACLE_HOME/OPatch/opatch lsinventory | egrep "38273545|38291812|38194382|19\.29"

SQL patch registry

select patch_id, patch_type, action, status,
       to_char(action_time,'DD-MON-YYYY HH24:MI') action_time
from dba_registry_sqlpatch
order by action_time desc;

Component status

select comp_id, comp_name, version, status
from dba_registry;

Optional but useful checks

Invalid objects count (before vs after)
Listener status
Basic EBS login smoke test (if apps involved)
Concurrent manager sanity (if your change plan includes it)

7) Common issues and quick DBA fixes

OPatch too old

Symptom: Patch fails at start
Fix: Upgrade OPatch to the required version first.

Conflict with one-off patches

Symptom: Conflict detected
Fix: Use MOS Conflict Checker and request merged patch if needed.

datapatch errors

Symptom: SQL patch not registered / failures
Fix: Review datapatch logs, ensure DB/PDB state is correct, and rerun datapatch after fixing root cause.

Conclusion

Applying CPU + OJVM patches on an EBS database is not hard—but it must be disciplined. For Oct 2025 on 19c Linux x86-64, you can either:

Go with the Combo patch for simplicity, or
Apply DB RU then OJVM separately for flexible scheduling

Either way, the real success factor is: conflict check + clean datapatch + solid validation.

Tuesday, February 10, 2026