OJVM patching fails with ORA-1403 in 19.30 if JAVAVM is not installed

Thanks to all the people (Jeff, Daniele, Lothar and others) who alerted me about this topic. Some of you had even created their own fix already. So, this is about an issue which happens only if you have no JAVAVM installed in your database or PDB but you still apply the OJVM Bundle on to of the Oracle Database 19.30 Release Update. You may find then: OJVM patching fails with ORA-1403 in 19.30 if JAVAVM is not installed.

When does this happen?

This issue happens when you apply the OJVM bundle together with or on top of an installation 19.29 or 19.30 Release Updates (RU) are applied. But at the same time, you don’t have JAVAVM present in REGISTRY$ in your database. This is not an uncommon case since some of you have JVM present in CDB$ROOT only but not in PDB$SEED and individual PDBs.

Therefore, this may have hit many customers already.

You won’t see the issue when the JAVAVM component is in REGISTRY$ or DBA_REGISTRY of your database or PDB.

So, in summary, you installed RU 19.30 (38632161) either together with, or later applied OJVM bundle (38632161) where you had either JAVAVM no installed in your database, or JAVAVM installed selectively in several but not all container.

 

What is the error you may see?

In the above cases, datapatch is going to fail with this error:

Patch 38523609 apply (pdb PDB_TEST): WITH ERRORS (PREV PATCH)
logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/38523609/28341036/38523609_apply_CDBTEST_PDB_TEST_2026Jan24_15_05_55.log (errors)
-> Error at line 948: script javavm/install/bug35933540_apply.sql
- ORA-01403: no data found
- ORA-06512: at line 5

Further down, this is the actual issue:

SQL> declare
 2   stat varchar2(30);
 3  begin
 4
 5    select status into stat from dba_registry where comp_id = 'JAVAVM';
 6    if stat != 'REMOVED' then
 7      begin
 8        execute immediate 'revoke read on SYS.DBA_JAVA_CLASSES from PUBLIC';
 9        execute immediate 'revoke read on SYS.CDB_JAVA_CLASSES from PUBLIC';
10        execute immediate 'grant select on SYS.DBA_JAVA_CLASSES to select_catalog_role';
11        execute immediate 'grant select on SYS.CDB_JAVA_CLASSES to select_catalog_role';
12      exception
13      when others then
14        if sqlcode not in (-1927) then raise; end if;
15      end;
16    end if;
17  end;
18  /
declare
*
ERROR at line 1:
ORA-01403: no data found
ORA-06512: at line 5

When you switch now into the database or the individual container, it will tell you:

SQL> alter session set container=pdb_test;
Session altered.

SQL> select * from dba_registry where comp_id = 'JAVAVM';
no rows selected

Whether the component is present in the CDB$ROOT or not does not matter IMHO. It will fail regardless as soon as you apply the OJVM Bundle to this home as soon as you invoke datapatch.

 

Why does this happen?

The routine applying the changes for bug 38523609 misses the exception handling.
Therefore, with every call the routine will fail signaling an ORA-1403 in case no JAVAVM is installed.

 

The “solution”

Correction

MOS Note: KB867653 – ORA-01403 Occurs When Applying OJVM RELEASE UPDATE 19.30 has been removed since it did not propose a valid solution.

Many people apply the OJVM bundle on top of an Oracle Home just out of routine without having JAVAVM in any of their databases.

But many of you run either multiple databases from within one Oracle Home, and some have JAVAVM installed, and others haven’t. But it is even more common to have JAVAVM in the CDB$ROOT but neither in the PDB$SEED nor in any or just in some PDBs. The DBCA offers exactly this with the “Include in PDB” option you can deselect when you do a CUSTOM creation of a database. And exactly in those two cases the recommended solution from KB867653 didn’t help.

 

The real solution

There is another MOS note available, KB867506 – Datapatch Apply of Patch 38523609: OJVM RELEASE UPDATE 19.30.0.0.0 fails while running javavm/install/bug35933540_apply.sql with the error ORA-01403: no data found. And luckily, this points to

It ships a corrected version of the bug35933540_apply.sql file, and with this one you won’t see the error anymore.

So, in case you’ve hit the issue, you are going to apply Patch 38844367, and then invoke datapatch again.

Theoretically, you could also start datapatch again with:

./datapatch -ignorable_errors=ORA-01403,ORA-06512

and skip the errors. Since you don’t have JAVAVM installed (and only then you would see the errors, you could easily live with the fact that the calls fail. But generally, I would recommend that you use the fix instead.

 

This is a 19.30-only issue …?

At first, you won’t see this issue in any other RU according to the development team. Unfortunately, the fix for bug 35933540 which caused this “apply” problem has been missed in the inventory.xml, and therefore can’t be found or queried in oradiff either. Patch 38844367 which fixes the apply-problem has been included into 19.31 Release Update. Hence, you won’t see this issue in the April 2026 19c Release Update anymore. The fix should be listed in the coming Release Update’s inventory then correctly.
Well, I am not so sure anymore. 5 minutes after I published the blog post, I received a comment from Tom saying the same issue exists in 23.26.1. I am checking with the developers and may have a confirmation and update by end of this day.

 

Will this happen with Oracle AI Database 26ai, too?

Actually, no, it won’t. Even though the patch apply and rollback scripts got shipped, the fix itself is already in 23.4.0, and therefore no scripts need to be run. The owning developer confirmed this yesterday, and in addition I received confirmation that the fix got shipped before any RU in 23/26ai got released. Therefore, no action needed in this release(s). It is an issue in 19.30, and it can happen as written below during rollback, too.

 

Rollback?

In addition, there is one unsolved issue when you rollback the RU now and move back to 19.29. There you may then see the same issue again but in 19.29. It is in discussion how to solve this. Hopefully, not too many will rollback – but I know that many of you are carefully testing patch apply and rollback. Once we have a solution here as well, I will update the blog post. Thanks to my colleague Bastian who alerted me right after posting this.
In case you’ve been trapped during rollback, this workaround shared by Pavel (thanks!!) may be the quickest way to get out of it after starting the DB again in a lower home:<

./datapatch -ignorable_errors=ORA-01403,ORA-06512

 

Further Links and Information

–Mike