Java in the database – OJVM non-rolling patches – OJVM Removal

Question:

How can I find out if Oracle’s JVM is used in my database?

Answer:

This is unfortunately not as trivial as I thought initially …
Let’s start with:

Until Oracle version 11.2 or later, there was no way to confirm if Oracle JVM is not actively used in the database

However, what can be said is:
1) If there are non-Oracle schemas that contain java objects, then 3rd party products or user defined java programs could be actively using the Oracle JVM.
2) If there are Oracle schemas, other than SYS, that contain java objects, then other Oracle products or Oracle Applications could be actively using the Oracle JVM.  (For example, ORDSYS schema for Oracle Intermedia and APPS schema for Oracle Applications).
3) Even if all java objects are owned by SYS schema, there might still be user defined java objects in the SYS schema. 

If the total number of java objects owned by SYS is much greater than the totals shown above, then this is likely.  However, the totals shown above are for a fully installed Oracle JVM.  If the JVM is not fully installed, then the existence of user defined java objects in the SYS schema could still make the total number of java objects exceed the above totals. Therefore, there is no way to guarantee that the Oracle JVM is not in use.

For Oracle version 11.2 or later query the DBA_FEATURE_USAGE_STATISTICS view to confirm if the Java features are being used.

I’m not a JAVA/OJVM expert but I’d do the following:

    1. Check how many JAVA objects exist in your database:
      select owner, status, count(*) from all_objects
      where object_type like '%JAVA%' group by owner, status;
      
    2. lf the results is equal to 29211 in Oracle 12c (see MOS Note: 397770.1 for numbers in different releases) then there’s a good chance that JAVA is not in use inside the database as there are no additional user defined objects. But please consult this MOS Note for a clear understanding of the number of objects
      CLARIFICATION:
      For a minimal installation of Oracle JVM in the database (after only running initjvm.sql), the total number of valid java objects owned by SYS should look something like this.
    3. In addition you may run this script from MOS Note:456949.1 (Script to Check the Status or State of
      the JVM within the Database) to check for any user defined objects JAVA objects in your database
    4. Anyhow, before doing anything to your JAVA installation now keep in mind that there are dependencies. The following components require the existence of a valid JAVA installation in your database:
      Oracle Multimedia (formerly known as Intermedia)
      Oracle Spatial
      Oracle OLAP
      And even more important, as there are dependencies between components there may be also dependent objects belonging to these components in your database. So it’s not as simple as it looked initially – you’ll have to check if any of the dependent components is in use as well – and the numbers 4.-6. will apply to 11.2. databases only, not to Oracle 12c:

      1. How to Determine if Spatial is Being Used in the
        Database? (Doc ID 726929.1)
        Please be aware that having a user defined SPATIAL SDO Geometry object will NOT increase the number of existing Java objects compared to a default installation. Roy verified this (THANKS!). So you’ll have to make sure that you checked also the dependent components for being in use. 
      2. How To Find Out If OLAP Is Being Used (Doc ID 739032.1)
      3. How To Check If Oracle Multimedia Is Being Used In Oracle Version 11.2 (Doc ID 1088032.1)
      4. How to Determine if Ultra Search is Being Used? (Doc ID 738126.1)
      5. Warehouse builder has a note about how to uninstall it, but that (very badly written) note does not tell you how to determine whether OWB is in use
      6. Rules Manager and Expression Filter document installation and deinstallation in their developers guide
  1. And even more important, before doing anything to your JAVA installation please take a backup – even though you may believe that backups are just for wimpies you’ll better take one before 🙂
  2. Now the question is:
    Should you remove only JAVAVM component – or CATJAVA as well? Please see the section further below on this blog posting for more information.
    To remove only JAVAVM this script could do the job – but it will leave two INVALID Package Bodies (JAVAVM_SYS, JVMRJBCINV):

    SQL> @?/xdk/admin/rmxml.sql
    SQL> delete from registry$ where status='99' and cid = 'JAVAVM';
    SQL> commit;
  3. The execution of the removal scripts won’t de-register the component from DBA_REGISTRY – that’s why the manual de-registration is necessary.
  4. Even if I’d remove the entire JAVA stack including the XDK it will leave those two invalid objects  (JAVAVM_SYS, JVMRJBCINV).
    SQL> @?/rdbms/admin/catnojav.sql
    SQL> @?/xdk/admin/rmxml.sql
    SQL> @?/javavm/install/rmjvm.sql
    SQL> @?/rdbms/admin/utlrp.sql
    SQL> delete from registry$ where status='99' and cid in ('XML','JAVAVM','CATJAVA');
    

    So honestly the best choice is always not to install things you clearly don’t need instead of trying to remove those things afterwards. In this case would now need to double check with Oracle Support if we’d safely can drop the two remaining  package bodies JAVAVM_SYand JVMRJBCINV. In my environment that worked well – but obviously I can’t give any official statement here.

    Again, please don’t get me wrong:
    I don’t say that you should remove JAVA from your databases And please check back with Oracle Support before doing this. But the question came up so often in the past months because of the OJVM patch which does not allow a rolling PSU upgrade anymore. For further information please see the following MOS Note and refer to my previous post quoting one of our Java experts:

    .

    So let’s do a quick experiment.

    Check the installed components in a standard Oracle 12.1.0.2 database first:

    SQL> select substr(comp_id,1,8) COMP_ID, substr(COMP_NAME,1,36) COMP_NAME from dba_registry;
    
    COMP_ID    COMP_NAME
    ---------- ------------------------------------
    DV         Oracle Database Vault
    APEX       Oracle Application Express
    OLS        Oracle Label Security
    SDO        Spatial
    ORDIM      Oracle Multimedia
    CONTEXT    Oracle Text
    OWM        Oracle Workspace Manager
    XDB        Oracle XML Database
    CATALOG    Oracle Database Catalog Views
    CATPROC    Oracle Database Packages and Types
    JAVAVM     JServer JAVA Virtual Machine
    XML        Oracle XDK
    CATJAVA    Oracle Database Java Packages
    APS        OLAP Analytic Workspace
    XOQ        Oracle OLAP API
    RAC        Oracle Real Application Clusters

    Before we’d be able to safely remove JAVAVM we will need to take out Spatial, Multimedia and OLAP (exactly in this order) as well.

    Spatial removal: 

    SQL> drop user MDSYS cascade;
    SQL> drop user MDDATA cascade;
    SQL> drop user spatial_csw_admin_usr cascade;
    SQL> drop user spatial_wfs_admin_usr cascade;

    After this action you’ll end up with 5 invalid objects in APEX in case APEX is installed. I think you can safely ignore them as those are spatial objects in the FLOWS-APEX schema:

    PACKAGE: WWV_FLOW_SPATIAL_INT, WWV_FLOW_SPATIAL_API
    PACKAGE BODY: WWV_FLOW_SPATIAL_INT, WWV_FLOW_SPATIAL_API
    SYNONYM: APEX_SPATIAL

    Multimendia removal:

    SQL> @?/rdbms/admin/catcmprm.sql ORDIM

    OLAP removal:

    SQL> @?/olap/admin/olapidrp.plb
    SQL> @?/olap/admin/catnoxoq.sql
    SQL> @?/olap/admin/catnoaps.sql
    SQL> @?/rdbms/admin/utlrp.sql

    Let’s do the check again:

    SQL> select substr(comp_id,1,8) COMP_ID, substr(COMP_NAME,1,36) COMP_NAME from dba_registry;
    
    COMP_ID    COMP_NAME
    ---------- ------------------------------------
    DV         Oracle Database Vault
    APEX       Oracle Application Express
    OLS        Oracle Label Security
    CONTEXT    Oracle Text
    OWM        Oracle Workspace Manager
    XDB        Oracle XML Database
    CATALOG    Oracle Database Catalog Views
    CATPROC    Oracle Database Packages and Types
    JAVAVM     JServer JAVA Virtual Machine
    XML        Oracle XDK
    CATJAVA    Oracle Database Java Packages
    RAC        Oracle Real Application Clusters
    

    12 components still there – SDO, ORDIM, XQO and APS are gone as expected.

    JAVAVM removal: 

    Question would be now to remove only the JAVAVM – or CATJAVA as well?
    As of MOS Note:397770.1 it seems to be that removing the JAVAVM is (a) trivial and (b) will avoid to apply the OJVM patch. So removing JAVAVM only seems to be the best way in this case. As shown above this will lead to two additional leftover package bodies JAVAVM_SYS and JVMRJBCINV.

    4) Oracle JVM is not installed in the database

    Do not apply the DST JVM patch.

    If for some reason the patch is applied, then apply the patch to the ORACLE_HOME but DO NOT run the post install steps in the database.  This will leave unwanted java objects in the database and create an incomplete non-working Oracle JVM.  See Note 414248.1 for details.

    SQL> @?/xdk/admin/rmxml.sql
    SQL> delete from registry$ where status='99' and cid = 'JAVAVM';
    SQL> commit;

    –Mike

25 thoughts on “Java in the database – OJVM non-rolling patches – OJVM Removal

  1. Seriously it’s 2015, we can’t we have:

    a) supported, documented and proven way for disabling any user from calling JVM/JRE at all (alter system set java_user_access=’off’ or even better something similar to revoke XXX from resource/connect/create session) – so even in SYS owned schemas (to reduce the attack surface)

    b) still, the whole RAC concept is dead if some JVM is vulnerable with CVE score of 10… why those OJVMs cannot be classical RAC rolling patches…

    -J.

  2. Jakub,

    I think the community ER system has been pushed for by the User Groups. Oracle people monitor it and participate. The idea is that people can vote and we get an idea if some things are really not pushed by one person only.

    Thanks
    Mike

  3. Hi Mike!

    I fear i don’t understand this whole OJVM patch thing.

    I patched the existing databases with the OJVM + PSU patches.
    This should solve the the OJVM vulnerability.

    Do i have to re-patch OJVM with every new PSU or is this bundle of OJVM-patch and PSU just for unpatched systems?

    Regards
    Andreas

  4. Hi Andreas,

    for Oracle 12.1 (and 11.2.0.4) at the moment all PSUs will be delivered in 3 editions:
    (a) the Database only
    (b) the OJVM only
    (c) the combo containing both

    If you take the combo (which I would do in any case in a single instance environment (non-RAC) then you’ll get the OJVM patch anyhow.

    Only RAC customers will have the trouble that the OJVM patch (and therefore also the combo) is non-rolling as it requires a restart of the database.

    And yes, to answer your question, all subsequent PSUs for 11.2.0.4 and 12.1.0.x will show the same behavior. So you’ll face this everytime you’ll apply a new PSU.

    This maybe changed in a future edition of the Oracle database …

    Cheers
    Mike

  5. Joseph,

    we all know that this is very disappointing. I have updated the blog post to retrack to another post I’ve did in the past. Quoting from this post:

    Eric Maurice’s security blog:
    https://blogs.oracle.com/security/entry/october_2014_critical_patch_update
    "Due to the nature of the fixes required, Oracle development was not able to produce a normal RAC-rolling fix for these issues. To help protect customers until they can apply the Oracle JavaVM component Database PSU, which requires downtime, Oracle produced a script that introduces new controls to prevent new Java classes from being deployed or new calls from being made to existing Java classes, while preserving the ability of the database to execute the existing Java stored procedures that customers may rely on."

    Cheers
    Mike

  6. Hi Mike,
    Thanks for the info.
    In my databases, I checked all those and looks like we do not use those at all. If I do end up removing those components so I do not need to install the ojvm patch from now on, what should I do with the one I already installed (say the one from Jan 2016)? Should I rollback that one first (also run the deinstall sql?), then remove the above components? Or should I just let the patch sit there and just not apply new ones any more?

    Thanks!
    Erin

  7. Hi Mike,
    If it is determined that we are not using those four components, and we could remove them, and then no longer need to install the OJVM patch any more, What is the right sequence to do so?
    1. remove components, rollback the old ojvm patch?
    2. rollback the old ojvm patch, run the postdeinstall.sql? remove the components?
    3. leave the installed ojvm patch there, remove the components, no long apply the new ojvm patch any more?

    Could you please advise?

    Thanks!

  8. Hi Mike,
    Once I removed those components, should I uninstall the JavaVM patch? At that point I guess I do not need to run postdeinstall.sql any more, right? I am on 11.2.0.4 enterprise, and after I removed those components, I ended 85 invalid JAVA CLASS objects in sys, and 2 similar ones in exsys. What should I do with them? Any ideas?

    Thanks!

  9. Erin,

    in my understanding you will only take the correct PSU or BP in the next round (without the OJVM patch) and apply this one. opatch should take care on it.

    If it doesn’t please drop me an email please referring to your comment.

    Thanks
    Mike

  10. @zboa

    I would recommend (3) – otherwise please let me know. Opatch should take care of the binaries once you apply the next psu or bp.

    Thanks
    Mike

  11. Hi Mike

    Maybe there is a mistake in the point

    "lf the results is equal to 29211 in Oracle 12c (see MOS Note: 397770.1 for numbers in different releases) then I’d silently assume that JAVA is not in use inside the database as there are no additional user defined objects. "

    Because in the note 397770.1 for Oracle 12.1.x release If the total number of java objects owned by SYS is greater than or same as 29211 then Oracle JVM is correctly installed.

    thanks
    Luca

  12. Hi Mike,

    In your above post (good article by the way!), I see you have below line, does that mean you are removing the component "Oracle XML DB" as well?? I hope you can confirm because I am in the process to remove the JavaVM part, but I need to keep Oracle XML DB intact because it says it is used by utl_file etc, and we need those.

    SQL> delete from registry$ where status=’99’ and cid in (‘XML’,’JAVAVM’,’CATJAVA’);

    Thanks!

    Erin

  13. Hi Mike,

    On 12c, when I create a container database (using Advanced mode, custom database), it seems oracle does not let me de-select JAVAVM etc, it is all grayed out, does that mean on 12c I can’t removed the JAVAVM any more, and just have to live with it and patch it?

    Thanks,
    Erin

  14. Well, good question.
    My recommendation would be to not install it from beginning. Or create a new CDB without JVM, then remove it from the PDB and unplug/plug. Let me put this on my list of things to do …

    Cheers
    Mike

  15. Pingback: OJVM patch: Standby-First patching, yes or no? | Upgrade your Database - NOW!

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

Leave a Reply

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