Recently, I applied Oracle Database 19c MRP 19.31.0.0.260818 (Patch 39834048) to an Oracle RAC environment.
In this post, I’m sharing the actual commands I used, the important output from each step, and a couple of warnings I found during the patching process.
The main tools used were:
OPatchdatapatchopatch lspatches
Environment
The Oracle Home used for the patching was:
/u01/app/oracle/product/19.0.0/dbhome_1
First, I started the MRP installation with:
/u01/app/oracle/product/19.0.0/dbhome_1/OPatch/opatch napply /u01/patch/39834048
OPatch reported:
Oracle Interim Patch Installer version 12.2.0.1.52
Oracle Home : /u01/app/oracle/product/19.0.0/dbhome_1
OPatch version : 12.2.0.1.52
OUI version : 12.2.0.7.0
So the first thing to notice is that the Oracle Home was using OPatch 12.2.0.1.52.
OPatch Prerequisite Check
OPatch first checked the environment and showed the patches that were going to be installed:
OPatch continues with these patches:
38494116
38937302
39052286
39060241
39234501
39290842
39429942
39498075
39575331
39594515
39598920
39661089
39661105
39661114
39750798
39779336
It then asked:
Do you want to proceed? [y|n]
I selected:
y
The prerequisite checks completed successfully.
Stop the Database Before Patching
OPatch then reminded me that the Oracle instances using this Oracle Home needed to be stopped:
Please shutdown Oracle instances running out of this ORACLE_HOME
on the local system.
Is the local system ready for patching? [y|n]
After making sure the environment was ready, I selected:
y
OPatch then started applying the patches.
Applying the MRP
The patching process started with:
Backing up files...
Applying interim patch '38494116'
Then the remaining patches were applied one by one:
Applying interim patch '38937302'
Applying interim patch '39052286'
Applying interim patch '39060241'
Applying interim patch '39234501'
...
Applying interim patch '39750798'
Applying interim patch '39779336'
There were also some messages about optional components not being present:
Optional component(s) [ oracle.oid.client, 19.0.0.0.0 ]
not present in the Oracle Home or a higher version is found.
I didn’t treat these as errors because OPatch continued normally and the patch installation completed successfully.
OPatch Completed Successfully
At the end, OPatch gave the important confirmation:
Patches 38494116,38937302,39052286,39060241,39234501,
39290842,39429942,39498075,39575331,39594515,39598920,
39661089,39661105,39661114,39750798,39779336 successfully applied.
OPatch succeeded.
At this point, the Oracle Home was patched.
But we are not finished yet.
The next step is the database SQL patching.
Running Datapatch Sanity Checks
Before running datapatch, I ran:
/u01/app/oracle/product/19.0.0/dbhome_1/OPatch/datapatch -sanity_checks
The check completed successfully, but it showed two warnings that were worth looking at.
Most of the checks were:
Database component status - OK
PDB Violations - OK
Invalid System Objects - OK
Tablespace Status - OK
Backup jobs - OK
Temp file exists - OK
Temp file online - OK
Data Pump running - OK
Oracle Database Keystore - OK
Scheduled Jobs - OK
Central Inventory - OK
So overall, the environment looked healthy.
Warning 1 – PDB Was Mounted
One warning caught my attention:
Check: Container status - WARNING
The output showed:
Datapatch will only run in containers with READ WRITE,
MIGRATE (upgrade) or READ ONLY mode.
It also showed:
HOST_NAME NAME OPEN_MODE
rac-node1 TESTPDB MOUNTED
This is something to check before running datapatch.
If a PDB is expected to be patched, it needs to be in an appropriate state.
I normally check the PDB status with:
SELECT NAME, OPEN_MODE
FROM V$PDBS;
For example:
NAME OPEN_MODE
---------- ----------
PDB$SEED READ ONLY
TESTPDB READ WRITE
The important thing is to make sure the PDBs that should receive the SQL patch are open appropriately.
Warning 2 – Old Dictionary Statistics
The second warning was:
Check: Dictionary statistics gathering - WARNING
The reason was:
Data dictionary statistics are older than 7 days.
Oracle suggested:
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
EXEC DBMS_SYSTEM.GATHER_FIXED_OBJECTS_STATS;
This is worth checking before patching, especially in a production environment.
Run Datapatch
After the checks, I ran:
/u01/app/oracle/product/19.0.0/dbhome_1/OPatch/datapatch -verbose
Datapatch started:
SQL Patching tool version 19.31.0.0.0
Connecting to database...OK
Gathering database info...done
It then checked what was already installed.
Datapatch Found an Interim Patch
The important part of the output was:
Current state of interim SQL patches:
Interim patch 39060241 (Fix for Bug 39060241):
Binary registry: Installed
PDB CDB$ROOT: Not installed
PDB PDB$SEED: Not installed
PDB TESTPDB: Not installed
This is a good example of why we need both OPatch and datapatch.
The binary patch was already installed in the Oracle Home, but the SQL part had not yet been applied to the database.
Datapatch therefore added patch 39060241 to the installation queue.
Datapatch Installation Queue
The queue showed:
For the following PDBs:
CDB$ROOT
PDB$SEED
TESTPDB
No interim patches need to be rolled back
No release update patches need to be installed
The following interim patches will be applied:
39060241 (Fix for Bug 39060241)
Everything looked as expected.
Datapatch then started installing it.
SQL Patch Applied Successfully
The output showed:
Patch 39060241 apply (pdb CDB$ROOT): SUCCESS
Patch 39060241 apply (pdb PDB$SEED): SUCCESS
Patch 39060241 apply (pdb TESTPDB): SUCCESS
And finally:
SQL Patching tool complete
So the SQL patching completed successfully for all three containers.
Check the Installed Patches
After completing the patching, I checked the Oracle Home using:
/u01/app/oracle/product/19.0.0/dbhome_1/OPatch/opatch lspatches
The output included:
39779336;Fix for Bug 39779336
39750798;Fix for Bug 39750798
39661114;Fix for Bug 39661114
39661105;Fix for Bug 39661105
39661089;Fix for Bug 39661089
39598920;MERGE ON DATABASE RU 19.31.0.0.0 OF 39060101 39127997 39128024
39594515;Fix for Bug 39594515
39575331;Fix for Bug 39575331
39498075;MERGE ON DATABASE RU 19.31.0.0.0 OF 39360889 39370763
39429942;DB_DOMAIN NAME CHANGED TO UPPER CASE AUTOMATICALLY
39290842;Fix for Bug 39290842
39234501;Fix for Bug 39234501
39060241;Fix for Bug 39060241
39052286;Fix for Bug 39052286
38937302;AFTER APPLYING 19.30 DBRU THE AUTOTASK SQL TUNING ADVISOR GETS ORA-13602
38494116;Fix for Bug 38494116
39034528;Database Release Update : 19.31.0.0.260421
36240578;OCW RELEASE UPDATE 19.23.0.0.0
And, most importantly:
OPatch succeeded.
Don’t Forget DBA_REGISTRY_SQLPATCH
I also recommend checking the SQL patch registry after running datapatch.
Run:
SELECT
PATCH_ID,
ACTION,
STATUS,
ACTION_TIME,
DESCRIPTION
FROM DBA_REGISTRY_SQLPATCH
ORDER BY ACTION_TIME DESC;
For the interim patch we applied, you can specifically check:
SELECT
PATCH_ID,
ACTION,
STATUS,
DESCRIPTION
FROM DBA_REGISTRY_SQLPATCH
WHERE PATCH_ID = 39060241;
The expected result should show the patch as successfully applied.
OPatch vs Datapatch
One thing that can sometimes confuse people when patching Oracle Database is the difference between opatch and datapatch.
Simply put:
OPatch
|
+--> Patches Oracle Home binaries
and:
Datapatch
|
+--> Applies SQL changes to the database
So this:
OPatch succeeded.
does not necessarily mean the complete database patching process is finished.
I always check both sides.
Final Verification
After patching, my basic checklist is:
1. Check Oracle Home
opatch lspatches
2. Check SQL patches
SELECT PATCH_ID, ACTION, STATUS
FROM DBA_REGISTRY_SQLPATCH
ORDER BY ACTION_TIME DESC;
3. Check PDBs
SELECT NAME, OPEN_MODE
FROM V$PDBS;
4. Check invalid objects
SELECT OWNER, OBJECT_NAME, OBJECT_TYPE
FROM DBA_OBJECTS
WHERE STATUS <> 'VALID';
5. Check database components
SELECT COMP_ID, COMP_NAME, VERSION, STATUS
FROM DBA_REGISTRY
ORDER BY COMP_ID;
Conclusion
For this patching exercise, Patch 39834048 – DATABASE MRP 19.31.0.0.260818 was successfully applied to the Oracle 19c Oracle Home.
The overall process was:
Patch 39834048
|
v
OPatch prerequisite checks
|
v
Stop database instances
|
v
OPatch napply
|
v
Oracle Home patched
|
v
datapatch -sanity_checks
|
v
Review warnings
|
v
datapatch -verbose
|
v
SQL patch applied
|
v
opatch lspatches
|
v
Final verification
The two warnings from datapatch -sanity_checks were particularly useful:
TESTPDBwas inMOUNTEDstate.- Dictionary statistics were older than seven days.
The actual SQL patching completed successfully, with patch 39060241 applied to CDB$ROOT, PDB$SEED, and TESTPDB.
For me, the main takeaway is simple:
Don’t just look for OPatch succeeded. Always check datapatch and DBA_REGISTRY_SQLPATCH as well.
That gives you confidence that both the Oracle Home and the database itself are properly patched.
The commands and outputs in this article are based on the actual patching session provided for this MRP.
Oracle 23.26.3.0.0 August 2026 GI MRP Patching Using OPatchAuto on Oracle RAC
Oracle Critical Security Patch Update Advisory – August 2026
Comments 1