dba_registry_sqlpatch/cdb_registry_sqlpatch Empty after Patch

Hi all!
So, I was checking a new environment and noticed the dba_registry_sqlpatch was empty, when it actually shouldn’t:

SQL> select patch_id, patch_uid, version, action, action_time, status, description from dba_registry_sqlpatch;

no rows selected


The expected output should be (from another CDB in same home):

---------- ---------- -------------------- --------------- --------------------------------------------------------------------------- --------------- ----------------------------------------------------------------------------------------------------
  24917972   20791781		   APPLY	   37-APR-17 AM 					       SUCCESS	       Database PSU, Oracle JavaVM Component (JAN2017)
  24732082   20904347		   APPLY	   17-APR-17 AM 					       SUCCESS	       DATABASE PATCH SET UPDATE
  24917972   20791781		   ROLLBACK	 29-NOV-17 PM 					       SUCCESS	       Database PSU, Oracle JavaVM Component (JAN2017)
  26635845   21564421		   APPLY	   29-NOV-17 PM 					       SUCCESS	       Database PSU, Oracle JavaVM Component (OCT2017)
  26713565   21602269		   APPLY	   29-NOV-17 PM 					       SUCCESS	       DATABASE PATCH SET UPDATE
  27338041   22036385		   APPLY	   12-JUN-18 PM 					       SUCCESS	       DATABASE PATCH SET UPDATE

The result is basically the same if quering cdb_registry_sqlpatch.

Fist found the MOS dba_registry_sqlpatch or registry$sqlpatch View Is Not Reflecting the Complete Updated Information after Patching (Doc ID 2039738.1).
Problem is that is applies to 12.1 and it is caused by a bug in opatch version, but OPatch version is

$ORACLE_HOME/OPatch/opatch version
OPatch Version:

If this is a match for your, the proposed solution in that note is:

1. Download and use latest opatch version (Patch 6880880)
2. Take the backup & delete the contents of dba_registry_sqlpatch to remove the invalid entries:


3. Re-run the datapatch

But what was my problem then?
Well, after a while noticed the MOS Note Datapatch may skip the application of SQL payload for certain patches included in a given bundle in a RAC environment. (Doc ID 2069046.1).
It includes a PLSQL validation script, by the way. Have a look in case it’s a suspect.

And it was a match to me, seems the client used to had problems with opatchauto in the past and had to run the ‘datapatch -verbose’ manually.

The solution? To run this for every CDB contained in the cluster. The Registry$sqlpatch table is now reporting the correct patch history for all CDBs.

Hope it helps!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.