Thanks to colleague Patrick Roozen I learned that there’s a tiny little flaw in Oracle databases 12c patch procedures when using DBUA (upgrade) and DBCA (create custom database) when SPU/PSU/BP are installed on top of the base release. This is described by Mike Dietrich in a recent blog. Oracle Support Note 2047990.1 called “DBUA 12c and datapatch.pl” explains why DBUA does not call datapatch:
“The DBUA uses the “catctl.pl -x” option for executing catuppst.sql (the post upgrade script) in a separate step whereas on the command line catuppst.sql is run. The DBUA uses catcon.pl instead to execute catuppst.sql. In previous releases this was not an issue as catbundle.sql got automatically executed as part of catuppst.sql. But as datapatch.pl is a PERL script, and a PERL script cannot be run from within a SQL script,catuppst.sql can no longer call the post-patching activities. The DBUA in 18.104.22.168 misses this action as a separate task.”
It seems that DBCA suffers from the same mistake of not calling post-patching activities of SPU/PSU/BP installations.
It boils down to that you have to revisit 12c databases that were created earlier using DBCA, after its RDBMS ORACLE_HOME got patched with SPU/PSU/BP, if the patches are only registered in the binary registry and not in the SQL registry. Use datapatch -verbose to find out.
This behaviour is not what you would expect and may require downtime if you still have to apply the database part of the patch using datapatch, e.g. as is the case when applying Patch 21068507 (Database PSU 22.214.171.124.4, Oracle JavaVM Component (Jul2015) which requires the database to be restarted in UPGRADE mode first. This is what I got after running datapatch -verbose when my 126.96.36.199 database wasn’t in UPGRADE mode:
Error: prereq checks failed!
patch 21068507: The database must be in upgrade mode
Prereq check failed, exiting without installing any patches.
Andre van Winssen