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

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” 
  

Important Notes

• MOS Note: 1929745.1 – Oracle JavaVM Component Database Patches
• MOS Note: 1940702.1 – Database JVM Vulnerabilities FAQ
• MOS Note: 2165212.1 – What to do if the Database JAVAVM Component becomes INVALID After installing an OJVM Patch?
  This Note contains a pretty detailed removal procedure for JAVAVM as well – I haven’t tried it out this way.

Facts and Things and Questions and Answers

• Q:
  When will I be affected by this issue with OJVM patching not being rolling and not Standby-First applicable?
  A:
  If you have a RAC system and/or if you don’t use a Physical Standby database for patching.
  If you have a regular stand-alone database, no RAC and no intension to do Standby-First Patching you can stop reading now.
• Q:
  Is this a one-time-only thing?
  A:
  No, the OJVM patching is a recurring topic.

• Q:
  Why does the Oracle JavaVM patch incur downtime?
  A:
  When OJVM gets patched we’ll have to:
  (a) update the Oracle executable … and …
  (b) run “CREATE OR REPLACE JAVA SYSTEM” which is a global step that updates classes.bin.
  The first part can be done one a per-node basis of course, but the second part requires interruption.
  

• Q:
  Do I have to patch all my homes?
  A:
  No, only the database homes are affected by the OJVM patch. But please be aware of the JDBC patch for client and GI homes. See MOS Note: 1929745.1 for a matrix and further details.

• Q:
  How do I find out if OJVM is present in my database?
  A:
  Please query: SELECT version, status FROM dba_registry WHERE comp_id=’JAVAVM’;
  If you get a return result OJVM is present in your database.

• Q:
  The Combo Patches combine OJVM and PSU together – should I take it?
  A:
  Well … very experienced ACS Engineers told me they’ll always take the separated patches, never the combos. If you don’t have OJVM anyways there’s no need to take the combo patches. And personally if I’d have to patch a critical system I’d prefer to keep things piece-by-piece. Just a guts feeling …
  So for example see MOS Note 1683799.1 – 12.1.0.2 Patch Set – Availability and Known Issues to patch a RAC and non-Exadata system. You’ll find this matrix:Non Exadata Real Application Clusters (RAC)

  Document	Description	Rolling RAC	Patch Download
  Note:23615334.8	Combo of 12.1.0.2.160719 OJVM PSU and 12.1.0.2.160719 DBBP (Jul 2016)	Part	Patch:23615334
  Note:23615308.8	Combo of 12.1.0.2.160719 OJVM PSU and 12.1.0.2.160719 GI PSU (Jul 2016)	Part	Patch:23615308
  Note:23273686.8	12.1.0.2.160719 Database Proactive Bundle Patch (Jul 2016)	Yes	Patch:23273686
  Note:23273629.8	12.1.0.2.160719 (Jul 2016) Grid Infrastructure Patch Set Update (GI PSU)	Yes	Patch:23273629
  Note:23177536.8	Oracle JavaVM Component 12.1.0.2.160719 Database PSU (Jul 2016) (OJVM PSU)	No	Patch:23177536

  I’d take the Proactive Bundle Patch (RAC Rolling) and if necessary the OJVM Component PSU (both marked in RED) instead. And even though the name does not say it, Patch:23273686 does contain the Database Bundle Patch and the PSU for the Grid Infrastructure (OCW is the acronym for Oracle Cluster Ware). But it does not include the OJVM patch.

• Q:
  If I don’t use Oracle JVM can I remove it?
  A:
  In theory, yes. But it is not as simple as it does look like. First of all it’s not that easy to detect if there’s REALLY nobody using OJVM in your database. And second there are a lot of other components and features dependening on JAVAVM such as Spatial/Graph and Multimedia. I tried to picture this here. And MOS Note: 2165212.1 does contain detailed steps as well.

• Q:
  Will the OJVM patching be rolling and standby-first again?
  A:
  There may be plans for a future release or patch set of the Oracle database.

Stay tuned …

–Mike