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

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

Who’s the Product Manager for Patching?

First of all, I’m neither a patching expert nor am I the Product Manager for Patching. There’s no such role as far as I know but there are people inside Oracle who have way more clue about this topic. There’s a group inside Oracle’s development owning this topic but I’m not working in this team.

Still I’m interested in patching.
Why? Simply because patching goes usually in conjunction with an upgrade or a migration first. Our recommendation for years is this straight forward approach:

  1. Download and install the most recent release (in most cases the newest patch set which is a full release since Oracle
  2. Then apply the most recent Bundle Patch (or Patch Set Update) on top
  3. Then apply the important one-off (single) patches on top (see our slide deck for a guided how-to)
  4. Then upgrade or migrate

This way you’ll make sure to avoid the most terrible issues known to Oracle already. Of course there’s no guarantee that this will avoid all potential issues and pitfalls. But when dealing with Oracle Support later on (or myself in case we work together on a reference project) it’s much easier for you and us as we won’t waste time to diagnose issues which are already fixed.

Ah, and there’s my background of 6 years of RDMBS mission critical support when I started at Oracle almost 20 years ago.

The OJVM Drama or Saga

Well … procrastination is a terrible but very human habit. The OVJM topic is on my radar for 6 months now. Actually even longer but more and more people approached me in the past months asking so many questions about OJVM patching. And I realized that I don’t have an answer in all cases. As I said above, I’m not a patching expert.

What is this thing I’m calling the OJVM drama or saga? And what the heck is OJVM?

Very important:
If you don’t have a RAC (Real Application Clusters) system or intend to do Standby-First Patching (see MOS Note: 1265700.1 – Data Guard Standby-First Patch
) you can stop reading here. This “drama” won’t affect you at all.

OJVM is the Oracle Java Virtual Machine which gives you the ability to execute JAVA code directly in the database. The glossary says: “A standard, Java-compatible environment that runs any pure Java application“. If you intend to search for it please use “Oracle JVM” or “JVM” but not “OJVM” as it is not known in the documentation as OJVM.

The saga started actually with the October 2014 PSU (Patch Set Update). It included a patch for the Oracle JVM which required the database to be restarted. And this meant that the patch is not RAC rolling installable anymore.

Older Blog Posts about OJVM?

Yes of course, I did blog about this already:

But my focus in these posts is to show you potential solutions and share my experience with workarounds.

So please stay tuned 😉


Share this:

20 thoughts on “The OJVM Patching Saga – and how to solve it – Part I

  1. Hi ,
    above you seem to say that if one does not have a RAC system , so only single instance database , then we don’t need to apply the OJVM? Is this correct and can you point me to a doc in MOS where this is stated?


  2. Anthony,

    no – this is not what I’m saying. I’m saying that if you don’t have a RAC or a Standby where you do Standby-First Patching you don’t have to take care on the inconveniences of OJVM patching restrictions as you can’t do a rolling PSU or BP upgrade anyways in a single instance environment.

    Therefore you won’t see any difference regarding the patching process on single instance, no matter if you have OJVM or not.

    And no, if you have OJVM you MUST apply the patches as otherwise you’ll miss the security fixes. Or you’ll use the mitigation patch to disable the java subsystem. Or you don’t install OJVM to bypass those things.


  3. Pingback: The OJVM Patching Saga – and how to solve it – Part II | Upgrade your Database - NOW!

  4. Pingback: The OJVM Patching Saga – and how to solve it – Part III | Upgrade your Database - NOW!

  5. Pingback: The OJVM Patching Saga – and how to solve it – Part IV | Upgrade your Database - NOW!

  6. Pingback: The OJVM Patching Saga – and how to solve it – Part V | Upgrade your Database - NOW!

  7. Pingback: JAVAVM and XML Clean Up in Oracle Database 11.2-12.2

  8. Hi Mike,
    currently I’m patching our 12.2 and 12.1 GI/RDBMS env. with RU Jan 2018 and OJVM under OL 7.4. No problems (opatchauto made a good job).
    But I noticed some interessting difference in OJVM Readmes.
    In the 12.1 you can potentially patching a cluster OJVM in rolling manner in 12.2 there is no way to do that (regarding Readme). Do you know the reason?
    Cheers Peter
    Readme 12.1
    Patch 27001733 – Oracle JavaVM Component Database PSU
    This document describes how you can install Patch 26635845 – Oracle JavaVM Component Database PSU on your Oracle Database 12c Release 1 (

    This patch is not Oracle RAC Rolling installable. However, starting with the Jan2017 OJVM PSU patchset for, the OJVM PSU may be installed in a “Conditional Rolling Install” fashion for the following use cases:
    No OJVM usage
    OJVM used by non-critical jobs and programs
    OJVM used by critical functions isolated as services
    OJVM used extensively, not isolated, and downtime is tolerated
    OJVM used by critical functions and minimal downtime is required
    See My Oracle Support Document 2217053.1 for more details.

    This patch is Database Vault installable. Review My Oracle Support Document 1195205.1 for details on how to apply this patch to a Database Vault environment.
    Readm 12.2
    Patch 27001739 – Oracle JavaVM Component Release Update

    This document describes how you can install Patch 27001739 – Oracle JavaVM Component Release Update (OJVM RU) on your Oracle Database 12c Release 2 (
    This patch is not Oracle RAC Rolling installable.
    This patch is Database Vault installable. Review My Oracle Support Document 1195205.1 for details on how to apply this patch to a Database Vault environment.
    This patch is not Data Guard Standby First Installable.

      • Peter,

        the readme of 12.2 is faulty. No idea why copy/paste is so complicated and the same error happens over and over again.
        I have double-checked and sent an email to somebody who hopefully may trigger the correction. But no guarantee that it appears again … 🙁


  9. Hi Mike ,

    Need your suggestion realted to OJVM as per below :

    Before upgrading 11203 to 12201 , I have installed 12201 binaries and planning to install latest DB PSU(27105253) and OJVM(27001739).

    But as per readme of OJVM (27105253), I See below statement:

    If this OJVM RU is going to be installed after the installation of a DB RUR patch,
    then ensure that the post install steps for the DB RUR patch have already been completed prior to installing this OJVM RU.
    See Issue 2 in Known Issues for more information.

    My Question : Does that mean , we need to install only DB PSU(27105253) on top of 12201
    and then once we run (Catupgrd.sql in earlier version) or upgrade is finished , we need to apply OJVM Patch and then run datapatch ?

    Is my understanding correct ?

    Thanks / Malesh

    • Malesh,

      sorry for the inconvenience – and I highly recommend EVERYBODY to log SRs for such issues. Support (and the teams responsible for the Readmes) should learn about the pain customers like you have with such statements.

      This is what you should do:
      (1) Install software
      (2) Apply the January 2018 Update (RU) on top of it
      (3) If necessary, apply the January 2018 OJVM on top of it
      (4) Then upgrade your database to this release

      Part of the upgrade is the execution of datapatch which will apply all the required changes coming in with the patches to your database. No extra activity afterwards is necessary. Of course you won’t harm your database with a “datapatch -verbose” call from $ORACLE_HOME/Opatch – but this is not necessary.

      I think the readme refers to Revisions (RUR) for the case that you’ve had applied one.

      Hope this helps – and again sorry for the inconvenience!

      • Appreciate Mike for your quick response, In mean time i received the response from support as below.
        Hi Malesh,

        As discussed over call,follow the below steps.

        1.Install the DBRU patch on 12.2 home

        2.upgrade the database (datapatch will run during post upgrade steps)

        3.Please check the upgrade log whether datapatch completed successfully or not

        4.If datapatch failed during post upgrade steps please rerun the datapatch maually for the DBRU patch before installing the OJVM RU

        3. Install the OJVM RU

        4.Run post install steps for OJVM RU
        ——- end of support details – – – –

        Hope this helps others too…..

        • Malesh,

          can you give me the SR number please?
          I disagree with the step to do the OJVM separately after the upgrade. I don’t see why this should happen just after upgrade.


  10. Hi Mike,

    Is there an option to include OJVM patch with opatchauto in 12.2 rdbms ? I could not find it in readme.


  11. Hi Mike,

    I opened case with Orace support & got to know it’s possible to use “opatchauto” with OJVM, yet to test 🙂

    Hello Chaitra –

    You can use opatchauto if you are applying this OJVM patch. And Yes there is no documentation about it but it is understood to be the case for RAC. Or you can apply the single patch with the opatch apply command.

    • Many thanks for the update and for opening an SR, Chaitra!

      And it is quite surprising. “And Yes there is no documentation about it”. Hm …

      Thanks again!

Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required


I agree

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