JAVAVM and XML Clean Up in Oracle Database 11.2-19c

Posted on August 7, 2017 by JVM Removal 23

JAVAVM and XML Clean Up in Oracle Database 11.2-12.2JAVAVM and XML clean up in Oracle Database 11.2-19c is a tough topic. Many have suffered from the rolling patch upgrade issues with the OJVM (Oracle Java Virtual Machine) even though most of the issues have been cured with the recent patches.

Please see my previous blog posts starting here:

And please see also this very important MOS Note: 2217053.1 – RAC Rolling Install Process for the “Oracle JavaVM Component Database PSU” (OJVM PSU) Patches explaining the improved process for OJVM patching avoiding downtime in many cases.

JAVAVM and XML Clean Up in Oracle Database 11.2-19c

JAVAVM and XML Clean Up in Oracle Database 11.2-12.2Before you start removing anything from your database please make sure you read my introductory blog post about how to Remove and Clean Up Components from Oracle 11.2 – 19c . You’ll find links to monitor proper component removal there as well as in the SQL Scripts Repository on this blog.

In the database’s registry, the two components JAVAVM and XML are bound closely together. I will describe below how to remove both at the same time.

Please be aware that the removal of JAVAVM and XML will invalidate the dependent components:

  • Oracle Multimedia
  • Oracle Spatial
  • Oracle OLAP
  • Oracle Expression Filter
  • Oracle Rules Manager

as well. Please check and understand my blog post OJVM Removal from Jun 22, 2015 explaining more about dependent objects and components.

If you want to read and learn more about Oracle’s JVM please check this link:

Oracle Database 11.2.0.4

You will find the process for the JAVAVM removal in Oracle Database 11.2.0.4 clearly described in MOS Note:1112983.1 –  How to Reload the JVM in 11.2.0.x. Please check this note as it contains extra steps for verification. Basically the removal process looks like this:

$ sqlplus / as sysdba
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');
SQL> commit;

The recompilation is required. In my environments the database doesn’t have to be restarted or in upgrade mode as the above note implies. But as you’ll test this first in a test environment you may consider extra steps from the above note.

If you are removing JAVAVM in Oracle 11.2.0.4 make sure to remove also Rules Manager and Expression Filter as otherwise a subsequent upgrade will raise an error:

ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
PLS-00201: identifier ‘SYS.DBMS_JAVA’ must be declared

Thanks to B. Müller for alerting me on this missing puzzle piece (see the comments section below).

Oracle Database 12.1.0.2

In Oracle Database 12.1.0.2 the process to remove JAVAVM and XML is more or less the same as in Oracle 11.2.0.4. The only difference: you must clean up two objects after removal manually.

$ sqlplus / as sysdba
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');
SQL> commit;

As the process will result in two leftover packages you will have to clean up these manually:

$ sqlplus / as sysdba
SQL> drop package SYS.JVMRJBCINV;
SQL> drop package SYS.JAVAVM_SYS;

Then the removal process has been completed successfully.

Oracle Database 12.2.0.1 – 19c

non-CDB

The removal process in Oracle Database 12.2.0.1 for a non-CDB is exactly the same as in Oracle Database 12.1.0.2 for a non-CDB:

$ sqlplus / as sysdba
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');
SQL> commit;

As the process will result in two leftover packages you will have to clean up these manually:

$ sqlplus / as sysdba
SQL> drop package SYS.JVMRJBCINV;
SQL> drop package SYS.JAVAVM_SYS;

Then the removal process has been completed successfully.

CDB

At first, please be aware that there is a MOS Note: 2262919.1 (Repairing/Reinstalling JVM To A Multitenant Database (CDB and all PDBs) describing the theoretical removal process. But I learned from recent SRs that Support needs to correct your attempts as the note is incorrect. Please ask Support why the note isn’t updated when engineers know that it is incorrect and requires corrections. Using this note, you would stop after step (b). And I doubt that you need to remove EXF (Expression Filter) since this option did never exist in 12c – and Multitenant does not exist in 11g.

So you’ll find below my removal process.

It looks of course different to a non-container database due to the need to execute the removal scripts with catcon.pl.

First of all you must execute the removal scripts. You can run them in all containers.

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -b catnojav -d '''.''' catnojav.sql 
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -b rmxml -d '''.''' rmxml.sql
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -b rmjvmx -d $ORACLE_HOME/javavm/install rmjvm.sql
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql

After these scripts completed, your REGISTRY$ looks like this in Oracle 19c:

    CON_ID COMP_ID    VERSION	      STATUS
---------- ---------- --------------- ---------------
	 1 CATALOG    19.0.0.0.0      VALID
	 1 CATJAVA    19.0.0.0.0      REMOVED
	 1 CATPROC    19.0.0.0.0      VALID
	 1 JAVAVM     19.0.0.0.0      REMOVED
	 1 ORDIM      19.0.0.0.0      VALID
	 1 RAC	      19.0.0.0.0      OPTION OFF
	 1 XDB	      19.0.0.0.0      VALID
	 1 XML	      19.0.0.0.0      REMOVED
	 2 CATALOG    19.0.0.0.0      VALID
	 2 CATJAVA    19.0.0.0.0      REMOVED
	 2 CATPROC    19.0.0.0.0      VALID
	 2 JAVAVM     19.0.0.0.0      REMOVED
	 2 ORDIM      19.0.0.0.0      VALID
	 2 RAC	      19.0.0.0.0      OPTION OFF
	 2 XDB	      19.0.0.0.0      VALID
	 2 XML	      19.0.0.0.0      REMOVED
...

After the mandatory recompilation is completed you need to create a script to remove the component entries from REGISTRY$. This script needs to be executed in each container separately to avoid ORA-65023 errors:

$ vi reg.sql
    delete from registry$ where status='99' and cid in ('XML','JAVAVM','CATJAVA');
    commit;

Execute the script in each container, one after another:

$ORACLE_HOME/perl/bin/perl catcon.pl -c 'PDB2' -n 1 -b reg_pdb2 -d $ORACLE_HOME/rdbms/admin reg.sql
$ORACLE_HOME/perl/bin/perl catcon.pl -c 'PDB1' -n 1 -b reg_pdb1 -d $ORACLE_HOME/rdbms/admin reg.sql
$ORACLE_HOME/perl/bin/perl catcon.pl -c 'PDB$SEED' -n 1 -b reg_seed -d $ORACLE_HOME/rdbms/admin reg.sql
$ORACLE_HOME/perl/bin/perl catcon.pl -c 'CDB$ROOT' -n 1 -b reg_cdb -d $ORACLE_HOME/rdbms/admin reg.sql

 

With an Oracle 12.2.0.1 database, we are all set.

Oracle Database 19.8.0 and newer

But since Oracle Database 19.8.0, there is a significant change in the java removal script – and this leads to leftovers. Unfortunately a lot of them.

Annotation:

If you intend to remove JVM from a Multitenant environment after 19.8.0 I highly recommend that you open an SR and discuss and chase Oracle Support. Customers reported several issues with my process below. This starts with leftover objects to “not dropped from PDB$SEED” and more. It is not under my control. And I know that Support needs to fix and adjust the procedures published on MOS. I asked for a bullet proof routine but so far there doesn’t seem any. So please please, check and discuss with Oracle Support. The below routine may not work flawless anymore unfortunately due to changes in the removal scripts.

 

And in addition, there is an issue with rmjvm.sql since Oracle 18c (and fixed only with 21c and newer with no backports yet)

Be aware that the MOS note may not be complete. It does not refer to the bug and gives advice on doing an UPDATE statement directly in the dictionary. Before you do this by yourself, open an SR and double-check with Oracle Support. Ensure that Support, once confirmed, adds the above bug number to your SR in the SR header page. The result of this issue will be that a DROP USER … CASCADE will fail.

So I will create two cleanup scripts:

  • Cleanup in the PDBs: drop_from_pdbs.sql 
    DROP PACKAGE BODY SYS.DBMS_JAVA;
DROP PACKAGE BODY SYS.JAVAVM_SYS;
DROP PACKAGE BODY SYS.JVMRJBCINV;
DROP PACKAGE BODY SYS.OJDS_CONTEXT; 
DROP SYNONYM SYS.OJDS$ATTRIBUTES$;
DROP SYNONYM SYS.OJDS$BINDINGS$;		       
DROP SYNONYM SYS.OJDS$INODE$;		       	
DROP SYNONYM SYS.OJDS$NODE_NUMBER$;	       	
DROP SYNONYM SYS.OJDS$PERMISSIONS$;	       	
DROP SYNONYM SYS.OJDS$REFADDR$;		       	
DROP SYNONYM SYS.OJDS$SHARED$OBJ$;	       	 
DROP SYNONYM SYS.OJDS$SHARED$OBJ$SEQ$;
  • Cleanup in CDB$ROOT: drop_from_cdb.sql 
    DROP PACKAGE BODY SYS.DBMS_JAVA;

Execute the two scripts:

$ORACLE_HOME/perl/bin/perl catcon.pl -S -n 1 -b drop_from_pdbs -d $ORACLE_HOME/rdbms/admin drop_from_pdbs.sql
$ORACLE_HOME/perl/bin/perl catcon.pl -c 'CDB$ROOT PDB$SEED' -n 1 -b drop_from_cdb -d $ORACLE_HOME/rdbms/admin drop_from_cdb.sql

And now everything is clean again.

Component Clean Up Series

Finally download a slide deck about the Component Clean Up on this blog:
https://mikedietrichde.com/slides/

Share this:

Tags:

You may also like...

23 Responses

  1. B. Müller says:
    January 16, 2019 at 09:56

    Hi,
    just upgraded a 11.2.0.4 DB to 12.2.0.1.
    On this DB the JAVAVM was removed (in 11.2.0.4) with the commands from this post.
    The upgrade failed with
    ORA-06550: line 1, column 7:
    PL/SQL: Statement ignored
    PLS-00201: identifier ‘SYS.DBMS_JAVA’ must be declared

    The JAVAVM removal process wasn’t complete. One more script must be run for acomplete removal:
    @?/rdbms/admin/catnoexf.sql
    It is also listed in the MOS articel linked in the post.

    Upgrade went fine after running the script.

    If you are wondering what I did with the failed upgrade:
    Just flashed back the Database to a guaranteed restore point created just before the upgrade.

    Regards,
    B. Müller

    Reply
  2. Klaus says:
    March 26, 2019 at 07:20

    Why do you remove the deinstalled components from registry by:

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

    As far as I know when the status is “REMOVED” an upgrade/patch will not be performed for those components.
    Raise theses entries any trouble with future upgrades? What is the reeason of the deleting?

    Reply
  3. Kari Jacobs says:
    April 18, 2019 at 17:39

    I understand that JavaVM is used for XSU, XDKJ & XDKC. Is there a query to run to determine if the database is using any of these 3 components of XDK? Or how XDK is being used in the database?

    Thanks!

    Reply
    • Mike.Dietrich says:
      May 6, 2019 at 10:45

      Hi Karl,

      the queries I’m aware of are all mentioned in:
      MOS Note: 2217053.1 – RAC Rolling Install Process for the “Oracle JavaVM Component Database PSU” (OJVM PSU) Patches
      But I have learned over time, that it is not simple to detect if a component is used or not. Unfortunately, this is not documented centrally nor is there a clear guideline for every component. Some have published queries on MOS, others haven’t or refuse to.

      Cheers,
      Mike

      Reply
  4. KARI JACOBS says:
    May 2, 2019 at 15:30

    Our application team isn’t sure if they are using XDK? Is there a query that can be run to determine if the application code is using it? Is it possible to just remove the xml by running @?/xdk/admin/rmxml.sql?

    Reply
    • Mike.Dietrich says:
      May 6, 2019 at 11:21

      Hi Karl,

      I commented below to your earlier question.

      I don’t think that you can remove only XDK as far as I remember. I think, it will leave a lot of invalid things. You either remove the entire block (as explained) or leave it inside.

      Thanks,
      Mike

      Reply
  5. Raul says:
    February 28, 2020 at 11:01

    Hi

    I tested with 19.6 non-cdb database, now I know that you tested until 12.2, but still.
    I did all the steps, there were no invalid objects left after the utlrp.sql (there was no need to drop 2 leftover packages JVMRJBCINV and JAVAVM_SYS, since these were already dropped), but I noticed, that there are some JAVA objects present after this.

    SQL> select object_type, count(1) from dba_objects where object_name like ‘%JAVA%’ group by object_type;

    OBJECT_TYPE COUNT(1)
    ———————– ———-
    INDEX 11
    SYNONYM 18
    PACKAGE BODY 2
    PACKAGE 2
    DIRECTORY 1
    TYPE 6
    SEQUENCE 1
    TABLE 12
    VIEW 21

    9 rows selected.

    Bear in mind these are all sys objects, not user defined java objects, since dba_feature_usage_statistics did not show usage for user.

    Also, these are all in VALID state, but is this normal behaviour, that some sys JAVA objects left present..?

    Reply
    • Mike.Dietrich says:
      March 4, 2020 at 11:12

      Who is the owner of these?
      And what is in your DBA_REGISTRY by then (select comp_id, status, version, owner from dba_registry order by 1;)

      Cheers,
      Mike

      Reply
  6. Ernest Kalwa, BMath, OCP, MCP says:
    September 2, 2020 at 21:26

    After running these commands on a 19.3.0 “vanilla” database (CDB and one PDB), I was left with the following invalid objects in the PDB (and PDB$SEED) that could only be dropped by using these commands (the CDB had no remaining invalid objects, and the JAVAVM and XML registry components were successfully removed from the CDB and PDBs):

    connect / as sysdba
    alter session set container = PDB1;

    col owner format a10
    col object_name format a30
    — list invalid objects…
    select owner, object_type, object_name
    from sys.dba_objects where status != ‘VALID’
    and object_type != ‘UNDEFINED’ — EXCLUDE Materialized-Views
    order by 1, 2, 3
    /

    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$ATTRIBUTES$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$BINDINGS$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$INODE$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$NODE_NUMBER$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$PERMISSIONS$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$REFADDR$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$SHARED$OBJ$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$SHARED$OBJ$SEQ$’);

    exec dbms_pdb.exec_as_oracle_script(‘drop package SYS.JAVAVM_SYS’);
    exec dbms_pdb.exec_as_oracle_script(‘drop package SYS.JVMRJBCINV’);
    exec dbms_pdb.exec_as_oracle_script(‘drop package SYS.OJDS_CONTEXT’);

    exec dbms_pdb.exec_as_oracle_script(‘drop package SYS.DBMS_JAVA_MISC’);
    exec dbms_pdb.exec_as_oracle_script(‘drop trigger SYS.OJDS$ROLE_TRIGGER$’);

    NOTE: for the PDB$SEED database you need to open it read-write to drop these objects! Command sequence shown here:

    connect / as sysdba
    alter session set container=PDB$SEED;

    col comp_id format a10
    col comp_name format a40
    col version format a20
    col status format a15
    select comp_id, version, status, comp_name from dba_registry order by 1;

    alter session set “_oracle_script”=TRUE;

    alter pluggable database pdb$seed close immediate instances=all;

    alter pluggable database pdb$seed OPEN READ WRITE;

    col owner format a10
    col object_name format a30
    — list invalid objects…
    select owner, object_type, object_name
    from sys.dba_objects where status != ‘VALID’
    and object_type != ‘UNDEFINED’ — EXCLUDE Materialized-Views
    order by 1, 2, 3
    /

    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$ATTRIBUTES$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$BINDINGS$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$INODE$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$NODE_NUMBER$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$PERMISSIONS$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$REFADDR$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$SHARED$OBJ$’);
    exec dbms_pdb.exec_as_oracle_script(‘drop synonym SYS.OJDS$SHARED$OBJ$SEQ$’);

    exec dbms_pdb.exec_as_oracle_script(‘drop package SYS.JAVAVM_SYS’);
    exec dbms_pdb.exec_as_oracle_script(‘drop package SYS.JVMRJBCINV’);
    exec dbms_pdb.exec_as_oracle_script(‘drop package SYS.OJDS_CONTEXT’);

    exec dbms_pdb.exec_as_oracle_script(‘drop package SYS.DBMS_JAVA_MISC’);
    exec dbms_pdb.exec_as_oracle_script(‘drop trigger SYS.OJDS$ROLE_TRIGGER$’);

    — list invalid objects…
    select owner, object_type, object_name
    from sys.dba_objects where status != ‘VALID’
    and object_type != ‘UNDEFINED’ — EXCLUDE Materialized-Views
    order by 1, 2, 3
    /
    — optional if needed…
    –@?/rdbms/admin/utlrp.sql

    select comp_id, version, status, comp_name from dba_registry order by 1;

    alter pluggable database pdb$seed close immediate instances=all;
    alter pluggable database pdb$seed OPEN READ ONLY;
    alter session set “_oracle_script”=FALSE;

    alter pluggable database pdb$seed close immediate instances=all;

    alter pluggable database pdb$seed OPEN READ ONLY;

    — list invalid objects…
    select owner, object_type, object_name
    from sys.dba_objects where status != ‘VALID’
    and object_type != ‘UNDEFINED’ — EXCLUDE Materialized-Views
    order by 1, 2, 3
    /

    Reply
  7. Manan Contractor says:
    August 13, 2021 at 11:53

    Hello,

    I am trying to uninstall OJVM from a contained database with 1PDB.Can you please tell me what you meant when you said you need to run following in all the containers.

    $ cd $ORACLE_HOME/rdbms/admin
    $ $ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -b catnojav -d /u01/app/oracle/product/12.2.0.1/rdbms/admin catnojav.sql
    $ $ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -b rmxml -d /u01/app/oracle/product/12.2.0.1/xdk/admin rmxml.sql
    $ $ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -b rmjvm -d /u01/app/oracle/product/12.2.0.1/javavm/install rmjvm.sql
    $ $ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d ”’.”’ utlrp.sql

    Did you mean CDB$ROOT, PDB$SEED and all application PDB’s?

    Thanks & Rgds
    M.H.Contractor

    Reply
  8. M.H.Contractor says:
    November 18, 2021 at 14:05

    HI Mike.

    I think i have managed to follow all the mentioned steps for removal of OVJM. Now after its removal, i tried to drop a new created common user and i came across “ORA-65047: Object SYS.OJDS_CONTEXT is invalid or compiled with errors in root.”

    As part of the above mentioned process, we remove OJDS_CONTEXT from all containers except CDB$ROOT. I can see the package (and not the body) in PDB$SEED and TST4 (app pdb) but i cannot see that in my CDB$ROOT. Is the lack of package in CDB$ROOT the issue or the presence of the package in the remaining container the issue? The package in question is OJDS_CONTEXT.

    Reply
    • Mike.Dietrich says:
      November 26, 2021 at 20:27

      Hi,

      I think I made an error in the last stage by missing the PDB$SEED. Please rerun the drop_from_pdbs.sql script against the PDB$SEED as well:

      $ORACLE_HOME/perl/bin/perl catcon.pl -c ‘PDB$SEED’ -n 1 -b drop_from_cdb -d $ORACLE_HOME/rdbms/admin drop_from_cdb.sql

      Then all should be fine.

      Sorry for that 🙁

      Cheers,
      Mike

      Reply
      • Sahar says:
        July 12, 2022 at 00:29

        Hi Mike,
        We tested the steps with 19.15 non-CDB database to CDB and we had the same issue of the JVM was not dropped from PDB$SEED even after running the script.
        To work around this issue, we had to open the PDB$SEED in Read Write then remove JVM

        Reply
        • Mike.Dietrich says:
          August 8, 2022 at 11:21

          Hi Sahar,

          I discuss with the JVM group for quite a while that their process needs to be refreshed and fixed. Well …
          catcon.pl should be able to do exactly what it is supposed to do – but there seem to be changes in the dropjava procedures which lead to issues now …

          Very frustrating – and sorry for the inconvenience,
          Mike

          Reply
  9. Thilakan says:
    November 23, 2021 at 13:47

    Hi Mike
    Would like to double check with you regarding the OJVM removal . We removed OJVM using your method for the 19c Container Database however there is some difference in the left over objects after the removal . In our environment ( 19.12 ( July RU ) )

    In CDB we have

    SYNONYM DBMS_JAVA
    PACKAGE DBMS_JAVA

    In PDB

    SYNONYM DBMS_JAVA
    PACKAGE DBMS_JAVA
    PACKAGE JVMRJBCINV
    PACKAGE OJDS_CONTEXT

    Are we ok to remove these left over packages and Synonyms ? Checking with you according to your document it says drop the package body rather than package spec ?

    Having the left over package spec OJDS_CONTEXT is preventing us from being able to drop a CDB user and producing an error

    Thanks for the help

    Reply
    • Mike.Dietrich says:
      November 26, 2021 at 20:41

      Hi Thilakan,

      the OJDS issue was cause by me missing the PDB$SEED in the last removal steps. I updated the blog post. Can you run please:

      $ORACLE_HOME/perl/bin/perl catcon.pl -c ‘PDB$SEED’ -n 1 -b drop_from_cdb -d $ORACLE_HOME/rdbms/admin drop_from_cdb.sql

      I assume you have a leftover in the PDB$SEED causing trouble.

      Cheers,
      Mike

      Reply
  10. Thilakan says:
    November 29, 2021 at 18:03

    Thanks Mike , appreciate your response . however this did not resolved our issue . it turned out that there is a metalink note to resolve the issue we had .

    ORA-65047 Error While Dropping User On PDBs (Doc ID 2803616.1)

    this basically helped us , it might help others as well who may come across after dropping ojvm.
    word of warning there is a typo on the metalink note with extra “)” which people should bear in mind to remove it

    Thanks for the help

    Reply
    • Mike.Dietrich says:
      December 15, 2021 at 19:43

      Hi Thilakan,

      thanks for sharing the note number with us:

      Oracle Support Document 2803616.1 (ORA-65047 Error While Dropping User On PDBs) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2803616.1

      But actually I’m not happy with this note.

      1. It lacks any connection to a bug. I did some research and it may be related to: BUG 30779964 – RMJVM.SQL BROKEN
      2. Patching the data dictionary is sort of … well … nothing I would just blindly do without Support’s clear recommendation
      3. Instead of writing “do this for all PDBs”, the MOS note rather should use the catcon.pl call instead since this ensures that this will be done on PDB$SEED as well

      So to summarize, I learned that this issue is causing trouble in 18c and 19c – and it may be fixed in 21c at earliest. There is no backport yet for any RU nor is there an inclusion into any RU yet.

      Thanks a lot!!
      Mike

      Reply
  11. Chida says:
    May 2, 2022 at 23:46

    Hi Mike,
    I’m in the process of removing OJVM from 2-node RAC having Oracle 19c in a non-CDB environment. Oracle have this note: How to properly remove the JVM from 11gR2 and newer standalone database instances (Doc ID 2541088.1) but not anything specific for RAC environment. Do you think I can follow the same steps for each Oracle RAC instance?

    Thanks,
    Chida

    Reply
    • Mike.Dietrich says:
      May 10, 2022 at 15:42

      Hi Chida,

      please check with Oracle Support. I don’t think that there are any specifics for RAC but to my knowledge the note is faulty and needs support treatment.

      Cheers,
      Mike

      Reply

Leave a Reply

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

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

Mike Dietrich
Oracle Senior Director of Product Manager for Database Upgrade, Migrations and Patching writing just another blog.

Opinions certainly are my own as is this page.

Archives

Categories

Upgrade @YouTube

Subscribe via Email

Join 12,434 other subscribers

Follow me on Twitter