The OJVM Patching Saga – and how to solve it – Part III

Related Posts on
“The OJVM Patching Saga – and how to solve it“:

• Part I – The OJVM Basics
• Part II – Important Notes and Information
• Part III – The Mitigation Patch
• Part IV – What you may have missed
• Part V – MOS Note explaining “Conditional Rolling Install” 
  

What is the “Mitigation Patch?

In MOS Note:1929745.1 – Oracle JavaVM Component Database Patches there’s a section called What is the Mitigation Patch. It says:
“For situations where the latest OJVM PSU cannot be installed immediately there is a “Mitigation Patch” that can be used. The “Mitigation Patch”
is an interim solution to protect against all currently known (Jul 2015) Oracle JavaVM security vulnerabilities in the database until such time
as the OJVM PSU can be installed. It can also be used to protect database versions no longer covered by error correction support.”

It is applicable to database homes only. And it makes sense only in databases where OJVM is present (see the previous blog post Part II – Important Notes and Information). It has no dependency on the PSU or BP, and it can be installed RAC Rolling. It’s a SQL patch. And finally it has been reviewed for use from January 2015 PSU onward.

The Mitigation Patch can be downloaded via Patch:19721304.

How to apply the Mitigation Patch

This is the official procedure when using the Mitigation Patch documented in MOS Note:1929745.1 – Oracle JavaVM Component Database Patches – and I flipped around some of the steps documented in this note as steps 5/6 in my list below are documented AFTER datapatch in the note – which won’t work.

1. Only if the patch is not included in your PSU/BP yet:
   Download the Mitigation Patch (Patch:19721304) and follow the readme to unzip it and do the patch prechecks
2. Shutdown the instances and services on the local node only
3. Apply the Database PSU (or Bundle Patch) but DO NOT RUN the post install steps
4. Only if the patch is not included in your PSU/BP yet:
   Apply the Mitigation Patch
5. Restart all databases on this node
6. Proceed with the next node(s)
7. Run post-install steps (for 12c: datapatch – for 11g: @?/sqlpatch/19721304/postinstall.sql )
8. This step is greatly missed in MOS and the patch documentation itself – it is mentioned in the PSU/BP readme:
   SQL> @?/rdbms/admin/dbmsjdev.sql
   on all databases running from this patched Oracle home(s)
9. SQL> exec DBMS_JAVA_DEV.DISABLE; on all databases running from this patched Oracle home(s)
   Note: This will enable the Mitigation Patch
10. At a later point, when you can take a complete outage:
    1. Disable public access to the database(s)
    2. SQL> exec DBMS_JAVA_DEV.ENABLE; in each database
       Note: This will disable the Mitigation Patch – without this step the PSU or BP can’t be applied
    3. Shutdown the database(s)
    4. Apply the OJVM PSU/BP patch
    5. Run OJVM PSU/BP post install steps on all databases in the patched home

Final Comments

First of all let me repeat that this is something which will affect customers with RAC systems only wou are used to apply PSUs or BPs in a rolling fashion. The Mitigation Patch is a workaround, not more than that.

Second personally I think that the cleanest way is to not have OJVM (JAVAVM component in DBA_REGISTRY) in your database when you don’t need it. This shouldn’t devalue OJVM at all. Even though I’m not a Java expert I know that OJVM has great value for some customers. But based on my internal polls I think that just a smaller number of customers relies really on it. Still, removing OJVM from an existing database can be quite complicated, especially due to the dependencies of other components. So the best way would be – if you know you won’t need OJVM – to not-install it when you create a database. It can always be created later on quite easily if required. But again, the devil is in the detail, you may need components depending on OJVM, and therefore you may have no choice.

–Mike