Parting with ocm.rsp isn't really sweet sorrow...

2 min read

Feb 7, 2017

Now that we're well into 2017, let's sit back and ask the question: "What was the best news of 2016 in the Oracle ecosystem?"

The 12.2 beta ? (no, that was announced in October 2015 :))
The fact that we now officially know that each PDB will have their own local UNDO ? (no, this was easy to guess)
The fact that we will be able to flashback a PDB ? (nope. This, too, was easy to guess)

I'll give you a clue. The best news was something that sneakily appeared between April and October 2016 in your patch maintenance logs : [code lang="sql"] [root@myclusterdb02 OPatch]# ./opatchauto apply /patches/OCT2016_bundle_patch/24436624/Database/12.1.0.2.0/12.1.0.2.161018DBBP/24448103 -oh /u01/app/oracle/product/12.1.0.2/dbhome_1 -ocmrf /u01/app/oracle/product/12.1.0.2/dbhome_1/OPatch/ocm/bin/ocm.rsp System initialization log file is /u01/app/oracle/product/12.1.0.2/dbhome_1/cfgtoollogs/opatchautodb/systemconfig2016-12-11_05-23-36PM.log. Session log file is /u01/app/oracle/product/12.1.0.2/dbhome_1/cfgtoollogs/opatchauto/opatchauto2016-12-11_05-24-09PM.log WARNING: the option -ocmrf is deprecated and no longer needed. OPatch no longer checks for OCM configuration. It will be removed in a future release. [/code] The interesting part is in that 4th line :

WARNING: the option -ocmrf is deprecated and no longer needed. OPatch no longer checks for OCM configuration. It will be removed in a future release.

This is awesome! We no longer need this annoying ocm.rsp file ! When I discovered this back in November 2016, I searched for an official feature announcement but found nothing (it looks like an opatch 13c new feature backported in 11g and 12c). This ocm.rsp file was still needed when I applied the April 2016 PSU, but from which opatch version was it implemented? First, I looked at the 2016 dev comments in opatch 11.2.0.3.15 and 12.2.0.1.7 (which were the last version when I was applying this Exadata October 2016 PSU) and I sadly discovered that no specific comments were talking about this new feature (even if it would obviously deserve some): [code lang="sql"] # opatch 04/08/16 Update CAS_VERSION to 12.2.0.1.3 # opatch 04/11/16 Consolidate all 4 opatch scripts # opatch 06/07/16 Calling auto_patch.pl using the perl from Oracle Home Location # opatch 06/30/16 bug 23721730 - default memory was too high for 32 bit so removed and disabled opatch_env.sh script call [/code] After a quick look at the code, I found the amazing piece of code that would ease our lives in the future (the function is named ocmOptionDetect()): [code lang="sql"] # Option 'ocmrf' is deprecated in OPatch 13.3 - Detect and give warning message if [ "$OCMRF_OPTION" = "1" ] && [ "$VERSION_13_X" = "1" ]; then echo "WARNING: the option \"-ocmrf\" is deprecated and no longer needed. OPatch no longer checks for OCM configuration. It will be removed in a future release." [/code] I then performed a few greps in different opatch versions that I had and I found that this feature has been implemented in:

11.2.0.3.13 or 11.2.0.3.14 for 11g (I was unable to find any of these versions so I couldn't check)
Between versions 12.1.0.1.10 and 12.2.0.1.7 for 12c (again, I was unable to find any of these versions so I couldn't check)

If you come across any of the opatch versions specified above, please " grep -i ocmrf opatch" it and let me know so I can find when this feature has been implemented. You can now upgrade all your opatches to become ocm.rsp-free and this (for me) was definitely the best new of 2016!

← SQL Server default configurations that you should change

A step-by-step look at MySQL returns results in a non-deterministic order. →

Get Email Notifications

No Comments Yet

Let us know what you think

Parting with ocm.rsp isn't really sweet sorrow...

Share this

You May Also Like

How to become an Oracle Certified Master (OCM)

Oracle Live SQL revised

Managing Oracle on Windows: Where’s my Oratab?

Get Email Notifications

No Comments Yet