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.

Photo by Michiel Leunens on Unsplash
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
- REMOVED: (KB867653) ORA-01403 Occurs When Applying OJVM RELEASE UPDATE 19.30
- (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
- Patch 38844367
- oradiff
–Mike
Oracle AI Database 23.26.1 has the same bug.
Has it??
Thanks, let me check this and tell the team.
I will update the blog post as soon as this is confirmed.
Did you open an SR, or did you just suffer from it?
THanks
Mike
Yes, 4-0002012011. That is for 19.30.
I checked all bug*_apply.sql scripts in the 23.26.1.0/javavm/install directory and only bug35933540_apply.sql does not have the check for no_data_found exception
Thanks Tom – I flagged this with the owning team and will get back later tonight.
Thanks
Mike
Hi Mike, does this only happen with RAC? I have a non-CDB database WITHOUT JavaVM installed on 19.30 and also applied OJVM patch to Oracle HOME. After running datapatch NO error appears..
Hi Peter,
no, this is independent of RAC/no RAC – it has to do with JAVAVM only.
Thanks,
Mike
I did rollback on a test machine and I am stuck in between now.
Waiting for the solution!
Hi Sven,
I hope to receive an update later tonight.
Thanks,
Mike
option a) find and modify rollback script to handle no_data_found exception
option b) run datapatch manually with -ignorable_errors=ORA-01403
Thank you, Pavel!!
Really like a lot that you share this with everyone!!
Challenge is only that the rollback scripts will be unpacked by datapatch from a ZIP stored inside the database. I am not sure (but had the same idea) whether we can modify the script and re-run datapatch again.
Cheers
Mike
Tested Option B, works for me after rolling back every OJVM Patch installed in this Oracle Home.
Thanks
Thanks – I checked with the developer, and he agreed as well.
Cheers,
Mike
Yes, I have 4-0002012011, but that is for 19.30.
Unfortunately the support engineer thinks that this is only for 19c, but it is also for 23.26.1.0 (on-prem).
/u01/app/oracle/product/23.26.1.0/javavm/install> ll bug*apply*.sql
-rw-r—– 1 oracle oinstall 1.6K Apr 15 2024 bug35728939_apply.sql
-rw-r—– 1 oracle oinstall 1.4K Feb 9 2024 bug35931412_apply.sql
-rw-r—– 1 oracle oinstall 1.4K Nov 30 2023 bug35933540_apply.sql
-rw-r—– 1 oracle oinstall 2.5K Apr 1 2025 bug37273777_apply.sql
-rw-r—– 1 oracle oinstall 6.7K Apr 1 2025 bug37273789_apply.sql
All check for the exception no_data_found, but bug35933540_apply.sql does not.
Thanks Tom – I hopefully will have an update later tonight.
Thanks
Mike
Tom, the script is in 23.26.1 but the issue won’t happen since the fix got shipped already in 23.4 – and this was the base release. Since this is a security fix, I can’t see but my mates confirmed it yesterday. Hence, you can ignore the faulty script missing the exception handling in 26ai.
Cheers,
Mike
I just ran into this today and NOW read your blog post about it. I applied the fix found in the community by adding an exception handler in your posting after line 16 in the 3 files in which the problem occurs. A the moment of patching, I wasn’t able to download 38844367 due to some strange error, after my patch windows, the file downloaded fine.
I like to suppose that this problem should be entered in
KB860153
Oracle Database 19.30 release Update January 2026 Known Issues
so other DBA have the chance to avoid getting into trouble
I did ask for that – and I did ask also to combine the two notes into one since it makes it much easier for everyone.
Let’s see how quickly this is going to happen.
Cheers,
Mike
Hello!
I have downloaded and applied 21.21 RU patch and OJVM +DB Update with autoupgrade on some hosts. Now waiting to get the new OJVM Update/PSU/Bundle Patches Oracle 19c (OJVM + GI Update) for Jan 2026 for GI hosts. When will be these patches avaiable on this link? KA958–>19c –> OJVM Update/PSU/Bundle Patches . or is there any other way i can download those? Regards /azhar
Hi Azhar,
21c has no OJVM anymore – in case you are waiting for it.
It is part of the RU since 21c, and no separate download anymore.
KA958 takes sometimes a little bit until the fixes are there. AutoUpgrade will fetch it automatically once it is available – and does not rely on the MOS note.
Cheers,
Mike
Hi Mike,
Yes, I know — that was just a typing mistake. My comment about OJVM + DB was referring to 19c. I’ve now downloaded all the patches and applied them in my test environments.
One thing I want to mention: when I applied the patches the first time using autoupgrade.jar in one of my test environments, the developers reported the next day that they couldn’t see the results from some BLOB columns in a table. We noticed that only some BLOBs with large sizes were affected. Because of this, I rolled back the patches.
The next day I found patch 38641793. I tested that patch together with RU 19.30 on one test environment, and it resolved the issue.
Yesterday I downloaded the OJVM + GI patches for my remaining environments and tested them on one test environment. Everything worked fine. Now I only have a few more Test and PROD environments left that still need the GI patching. Hopefully it will work smoothly there as well.
Regards
/Azhar
Thanks for the update, Azhar!
Cheers,
Mike
Do u apply patch 3844367 before you apply the ojvm ru, or after u apply the ojvm ru (and then rerun datapatch)? Seems like poor quality control on Oracles part.
Hi Paul,
well, our databases in testing don’t have this setup with OJVM in the home, and JAVAVM not configured in the database itself.
Therefore, this hasn’t been caught I fear.
You can apply the fix anytime – or you run datapatch with the ignore option I shared on the blog. Since there is no harm when there is no JAVAVM installed, there is no danger with it.
Cheers,
Mike
Hi Mike, has patch 38844367 been removed again? Can’t find it in patch search and https://updates.oracle.com/download/38844367.html also seems not to work.
Thanks, Manuela
Hi Manuela,
it has been recut and reuploaded on Feb 15.
I was not aware.
Thanks
Mike
Mike, better let Platinum support know. We just hit the bug during the patching of our Exadatas.
Hi Kirk,
they should know … 🙂
Cheers,
Mike
Mike, It seems Platinum support won’t apply the patch 38844367 and will only run ./datapatch -ignorable_errors=ORA-01403,ORA-06512 is that going to be an issue later on?
Hi Kirk,
I’d say “no, no issue later” if you only skip the errors with this script.
Ideally, what I’d do:
1. run datapatch
2. check the errors to make sure it happens only at this stage
3. run datapatch again, now with the ignorableerror flip
Since you have no JAVAVM installed in this case, there is no problem at all since the error happens only because the script does not catch the exception of having OJVM in the home but no JAVAVM component in the database or PDB.
Cheers,
Mike
Cheers,
Mike
Hi Mike,
i tried to downloaded the patch via autoupgrade mode download (Version 26.2.260205):
“There were conditions found preventing AutoUpgrade Patching from successfully running
*Downloading files
Cannot find the patch for bug 38844367”
patch=RU:19.30,OJVM:19.30,OPATCH,DPBP,JDK,SDOBP,27605010,26749785,34774667,34672698,37690446,38844367
I can download the patch 38844367 via https://updates.oracle.com/download/38844367.html manually.
Is this a Bug?
Best Regards,
David
Hi David,
I think you may have hit the time when the patch got removed briefly, then recut and uploaded again.
I was not aware that this happens but I see it from the time stamp on MOS.
Can you try again, please?
Thanks,
Mike
Hi David,
I learned today:
Unfortunately, AutoUpgrade is unable to locate patch 38844367, despite the fact that it is present in MOS.
There is a product limitation: currently, only RU-related patches may be downloaded, and this patch is for OJVM.
We are going to lift this in one of the coming versions.
Right now, you need to download it manually unfortunately.
Cheers,
Mike
unfortunately, Patch 38844367 works only during initial patching during application of 19.30, but doesn’t work during run of datapatch after PDB has been cloned/plugged/restored/… to/from non-19.30…
so, the only fix(if source or target has been infected by 19.30) is to use:
datapatch -ignorable_errors=ORA-01403
I see – luckily there is nothing really broken or dangerous but I agree, this is annoying.
Thanks
Mike
We hit this bug today and fixed it by applying Patch 38844367. Most of our databases have JVM installed as that component is in the default list. But the few dedicated to certain applications do not, because the software vendor explicitly says JVM is not needed.
I hope this kind of bug (“punishment” for those not having JVM installed) won’t happen again!
I hope the same, Yong!
Thanks,
Mike
> Why does this happen?
because either Oracle lacks the resources to thoroughly test their own recommended patches, or they find ok to throw untested releases to their customers, or both.
Nope – simply a human error – by an experienced person, btw.
Things can happen – we are all humans.
Sorry for the inconvenience!
Mike
>simply a human error
Yes, that is what i’m talking about. The fairly simple error that slips through all the tests unnoticed direct into release.
Even the mentioned patch 38844367 which suppose to sort things out, is
1) very poorly described (2nd node RAC blah blah), causing a lot of confusion among customers
2) still contains the rollback issue.
There were just 3 simple sql files to fix and that “experienced person, btw.” managed to fix only 2 of it. The patch has been released.
I personally don’t need excuses, the issue has been detected in our test environment, we delayed the deployment and it never made it to production.
I just hoped that with the question “Why does this happen?” Oracle internally asks itself “Why such a simple issue is not covered with our tests and how can we fix it in the future” and not comes with the answer “simply a human error”.
BR Alexey.
Hi Alexey,
I see your points, but again: Humans make mistakes. And trust me, the very experienced developer feels bad and sad about it since this shouldn’t have happened.
Regarding the bug description (or bug “subject” to be more precise) saying:
Bug 38844367 – 19.30 OJVM PATCH APPLY IS FAILING ON SECOND NODE IN RAC ENVIRONMENT WITH ERROR IN JAVAVM/INSTALL/BUG35933540_APPLY.SQL FILE
This is what the person who filed the bug entered into the bugDB. I agree with you that it has nothing to do with RAC or 2nd node – it is what the person wrote.
If the developer feels that it is misleading a lot, he or she can change that (I can’t). But we are working on the MOS note to make it more clear, and the actual subject of the bug entry shouldn’t play a bigger role.
The rollback topic can’t be fixed by the fix that easily.
This has to do with the mechanism on how the rollback scripts are bundled and preserved for a potential rollback.
But I shared a very simply workaround others shared with me – therefore, I agree, it is annoying – but it does not cause any issue beyond the annoyance.
Cheers,
Mike
Anyone else getting ora 17401 java.sql.SQLException: Protocol violation: [ 14, 2, ] after applying 19.30? One of our applications is not connecting properly after applying 19.30, but when rolling back it works, so curious if something is wrong with the 19.30 ojvm patch? I see the java jdk and jdbc in oracle home were updated with the 19.30 patch….
Did you log an SR – if not, then please do so.
Feel free to share the SR number with me.
Thanks
Mike
not yet, we just noticed this issue today… but I will create one shortly and share the number with you!
Did experienced that bug here too.
There is an OneOff for that.
Patch 38641793: X10M:FADB23:FA:ADMIN SERVER NOT STARTING — ORA-17401: PROTOCOL VIOLATION.: [ 14, 3, ]
It is already in the KB860153
Oracle Database 19.30 release Update January 2026 Known Issues
Oh good to know. thank you! I wish I understood where to find these kinds of documents better.
I checked that one off patch and unfortunately it is not available for windows. I will ask oracle support if they can provide one or have an ETA since we are running oracle on windows azure.
Another person asked that – I think you can copy in the script safely and overwrite the existing one.
But I guess the patch hasn’t been built or requested separately for Windows yet.
Mike
See also:
https://support.oracle.com/support/?kmContentId=11421216&page=sptemplate&sptemplate=km-article
==> KB868454
Cheers,
Mike
Just to clarify: that is another Problem with 19.30.
There is something wrong with Advanced Networking e.g. TLS/SSL and LOB/JSON
KB868454
java.sql.SQLException: ORA-17401: Protocol violation.: [ 14, 3, ] after Database January 2026 CPU Patch
One-Off Patch 38641793
Ohhhh … thanks, I read it now.
Solution
Either :
1. After applying Database Release Update 19.30.0.0.0 Patch:38632161, download and install Database Patch:38641793 on top
Or,
2. As a workaround in JDBC, you can set the JDBC property -Doracle.net.useZeroCopyIO=false.
This will get past the issue because it will have JDBC negotiate to disable VIO, rather than enable it as it does by default.
Check Oracle Database 19.30 release Update January 2026 Known Issues: KB860153
Thanks for sharing!
Mike
This bug only seems to be concerning JDBC connection when TCPS (TCP with SSL/TLS) is used. Two other documents, KB868454 and KB874948, also mention TCPS. We couldn’t recreate this error when using TCP (without SSL/TLS) and Oracle 19.30.
Could you please clarify that this bug only occurs with TCPS?
Martin,
not sure which bug you are referring to. The root cause for the fix itself (which then had the faulty “apply” and “rollback” script)?
thanks
Mike
Do you know where I can set that jdbc property? Should that be set in the client’s jdbc? We use TCPS, but I was able to get paste the protocol error by setting up a TCP port for our application to use temporarily, but it would be better to keep TCPS and set that property as a workaround while we wait for windows version of 38641793.
Hi Josh,
I really don’t know. You please need to check with Oracle Support.
Thanks
Mike
Hi Mike,
Can we apply the 38844367 on Windows x64, because the patch readme says “RDBMS SERVER Patch for Bug# 38844367 for Linux-x86-64 Platforms”, but in the Orion the Platform is Generic 🙂
BR Alexey
If it is generic (which it is supposed to be), then yes, technically you can copy the script into the home.
What you can’t do most likely is installing it directly (I fear). My guess is that the XML attached to the fix didn’t label it for windows.
Mike
Yes, linux is hardcoded…
therefore OPatch denies it
Prerequisite check “CheckPatchApplicableOnCurrentPlatform” failed.
The details are:
Patch ( 38844367 ) is not applicable on current platform.
Platform ID needed is : 233
Platform IDs supported by patch are: 226
Filed an SR 4-0002161837
BR Alexey.
Ok, then you have four options:
a) copy the file into the directory and overwrite the existing one manually
b) wait for the backport on Windows
c) wait for 19.31
d) use the datapatch call I share to ignore the error – ideally, run datapatch twice, first to make sure only this error comes up, and then with the “-ignore” option a second time.
Cheers,
Mike
they finally released 38844367 again, now generic.
Thanks for this update!!!
Cheers,
Mike
Hi Mike,
we run Multitanent PDBs in a Dataguard environment.
JavaVM is installed in the CDBs, but not in some PDBs.
The error also occurred in these PDBs.
Due to the scheduled downtime, we chose option 2: `./datapatch -ignorable_errors=ORA-01403,ORA-06512` to skip these step.
After a restart, these PDBs were no longer in restricted mode and were available.
However, after the first switchover, the PDBs on the other side went back into restricted mode.
How can we remove this status from the system without further downtime for applying fix bug 35933540 (option 1)?
BR Wolfgang
Hi Wolfgang,
sorry, I tried to answer your 2nd question at first. Now reading this.
I really don’t understand why the PDBs go into Restricted Mode after a switchover.
My fear is that you need to apply the fix then.
Cheers,
Mike
Hi Mike,
we run Multitanent PDBs in a Dataguard environment.
JavaVM is installed in the CDBs, but not in some PDBs.
The error also occurred in these PDBs.
Due to the scheduled downtime, we chose option 2: `./datapatch -ignorable_errors=ORA-01403,ORA-06512` to skip these step.
After a restart, these PDBs were no longer in restricted mode and were available.
Everything seems fine.
But after a switchover, the PDBs on the other side restarted in restricted mode again.
The same behavior occurred again after switching back.
best regards Wolfgang
Hi Wolfgang,
this is quite intersting. I fear you will need to apply the patch then on both sides.
Meanwhile, I try to understand why this happens.
When you ran datapatch on the primary, you skipped the errors. I wonder why — after a switchover — you received the same warnings/errors again?? Did you run datapatch another time?
Thanks
Mike
Hi Mike,
yes,
after every switchover I have to run the datapatch again on Primary to get the PDB out of restricted mode.
Wolfgang,
did you raise an SR?
If not, please do so and share the SR number with me.
I will forward it to the parties in charge directly.
Thanks
Mike
Hi Mike
i opened – SR 4-0002187925
thanks
Wolfgang
Thanks Wolfgang – I will forward it right away.
Cheers,
Mike
On Window platform apply 38844367 didn’t work!!
opatch apply H:\oracle_patch\19.30\38844367
Oracle Interim Patch Installer version 12.2.0.1.49
Oracle Home : e:\oracle\product\19c
OPatch version : 12.2.0.1.49
OUI version : 12.2.0.7.0
Verifying environment and performing prerequisite checks…
Prerequisite check “CheckPatchApplicableOnCurrentPlatform” failed.
The details are:
Patch ( 38844367 ) is not applicable on current platform.
Platform ID needed is : 233
Platform IDs supported by patch are: 226
UtilSession failed: Prerequisite check “CheckPatchApplicableOnCurrentPlatform” failed.
Has been re-released as a generic fix.
Thanks
Mike
Patch 38844367 is currently not available for download from MOS.
It is now – generic 🙂
Mike
fyi https://support.oracle.com/support/?patchId=38844367
works good with Theoretically Workaround too, thanks,
patch name:
19.30 OJVM PATCH APPLY IS FAILING ON SECOND NODE IN RAC ENVIRONMENT WITH ERROR IN JAVAVM/INSTALL/BUG35933540_APPLY.SQL FILE(Patch:Generic Platform)
is not accurate as this is failing also on single multitenant environment.
Well, it adopts it from the bug entry, and if the developer didn’t update it, it will be just taken into the labeling.
Not much I can do here – but you are right, this affects single instance as well of course.
Mike
encountered this issue in Prod but not in DR. should we be applying the patch only to Prod and leave the DR alone ?
You would not see the problem on DR since the patch would correct the statements on PROD, and the offending statements would not be arrive on DR.
Mike
We just installed RU19.31 in a dev-environment and this issue persists, although it was promised that 19.31 will include a fix.
The rollback issue persists I guess. But the fix for the up-patch is included in 19.31 as far as I have been told.
Cheers,
Mike
Yeah because 19.31 start with rollback of oneoff patch + 19.30JVM itself – that lead’s to error. I had to hack OEM fleet maintenace script to include workaround 😉
Validating logfiles…done
Patch 38523609 rollback: WITH ERRORS
logfile: /oracle/base/cfgtoollogs/sqlpatch/38523609/28341036/38523609_rollback_FM19TST_2026May06_11_33_30.log (errors)
-> Error at line 886: script javavm/install/bug35933540_rollback.sql
– ORA-01403: no data found
– ORA-06512: at line 5
Patch 38844367 rollback: WITH ERRORS (PREV PATCH)
logfile: /oracle/base/cfgtoollogs/sqlpatch/38844367/28466564/38844367_rollback_FM19TST_2026May06_11_33_30.log (errors)
-> Error at line 149: script javavm/install/bug35933540_rollback.sql
– ORA-01403: no data found
– ORA-06512: at line 5
Patch 39034528 apply: WITH ERRORS (PREV PATCH)
logfile: /oracle/base/cfgtoollogs/sqlpatch/39034528/28700584/39034528_apply_FM19TST_2026May06_11_33_30.log (no errors)
Patch 38906621 apply: WITH ERRORS (PREV PATCH)
logfile: /oracle/base/cfgtoollogs/sqlpatch/38906621/28588735/38906621_apply_FM19TST_2026May06_11_33_30.log (no errors)
What did you hack, Pavel?
Thanks,
Mike
upgradeDBUtility.pm in OEM – as we patch with feet maintence based on OEM
$finalCMD =$shellPath .” -x ” . $command . ” -ignorable_errors=ORA-01403″;
Please open an SR for this – I really can’t help here, as much as I would.
Cheers,
Mike
o.k getting the same errors i.e. ORA-01403 and ORA-06512 errors while applying the datapatch for 19.31. even though the home has the one-off patch ” 38844367:19.30 OJVM PATCH APPLY IS FAILING ON SECOND NODE IN RAC ENVIRONMENT”.
So, you are saying that the issue happens NOT during rollback (testing) but when you patch TO 19.31?
From which version do you patch to 19.31?
Thanks,
Mike
Hi Mike,
I’m still facing the same issue with OJVM 19.31 RU.
-> The bug is not listed in KB869205 (Oracle Database 19c RU, and BP Apr 2026 Known Issues),
-> The note “OJVM RU 19.31 Bugs Fixed List” is not available in KB106822.
-> I am not able to find a new version of Patch 38523609 (Bug 38844367) compatible with 19.31 OJVM RU.
Do you already know something about this?
Thank you
Joël
Hi Joel,
the fix is there but the implicit rollback for Java fixes is the problem. The rollback script has the same issue (no exception handling). I will release a blog post explaining this, and how to fix it.
Mike
This issue still exists in Apr2026
It is a rollback issue which happens implicitly – blog post will come.
Mike
This blog post by Christian Pfundtner might be helpful for some of you:
https://www.database-blog.at/2026/05/08/ru-vom-19-30-auf-19-31-liefert-ora-01403-ora-06512/
And we look forward to your post explaining the recommended workaround and how to move forward with this issue in future. Hopefully, this will finally be fixed in version 19.32 and all subsequent versions.
Mike, I am patching from 19.30 to 19.31. While applying the datapatch for 19.31 it rolls back the previous ojvm patch and during that time we are getting the same errors
when I applied 19.31 RU .. it removed the 38844367 one-off patch and hence while applying the datapatch same errors shown up. After applying the 19.31 patches .. look at the listing of patches as below:
38930593;JDK BUNDLE PATCH 19.0.0.0.260421
38906621;OJVM RELEASE UPDATE: 19.31.0.0.260421 (38906621)
39034528;Database Release Update : 19.31.0.0.260421 (39034528)
so the question is why would ORacle Remove the one-off patch 38844367 while applying the 19.31 patches. we already opened a case with ORacle.
Actually, the reason why it happens again is not the one-off – datapatch removes the changes from 19.30 OJVM with a rollback script which doesn’t have the error handling needed for such cases. There it fails.
Can you share the SR number, please?
Thanks
Mike
4-0002696340 is the SR. look at the comments from 7th MAy 2026 onwards
Thanks – I see the SR, and I see what Support says.
I will try to release an explanatory blog post tomorrow or on the weekend when time allows (it is completed by 50% already).
Cheers,
Mike
Hi Mike
Just curious if you’ve had time to complete your analysis. Looking forward to reading it as I’m facing this issue in my environment where we use Fleet automation so looking for a fix that doesn’t require running datapatch with ignorable_errors flag since I don’t know of a way to pass that parameter to datapatch view the Fleet procedures.
Interestingly, I’ve compared the javavm/install/bug35933540_rollback.sql with the apply.sql for the same bug in the new 19.31 Oracle Home and it appears to have the correct exception handling in place so I’m not sure why it’s triggering an error on rollback.
begin
select status into stat from dba_registry where comp_id = ‘JAVAVM’;
exception when no_data_found then
stat := ‘NOT FOUND’;
end;
Thanks and always enjoy your thorough analysis.
Hi Michael,
blog post will be out on Monday.
Thanks for your patience,
Mike
Hi Mike,
We will be performing the following workaround when performing out of place patching from Jan2026 to Apr2026
./datapatch -rollback 38523609,38844367 -verbose -ignorable_errors=ORA-01403,ORA-06512
./datpatch -verbose
We’ve spilt it into two steps as we wanted the ignorable_errors to only be applicable on the rollback of the problematic patches.
Hi Mike,
I use a gold image (19.30) to patch all the database fleet. A few of these databases does not have JAVAVM installed.
is it ok if I add the 38844367 patch to my gold image to apply to all the databases. I.e. will it also work for databases with JAVAVM installed.
Yes, this should work.
Thanks
Mike
I applied the fix before installing patch 19.30. Unfortunately, I get the same error when trying to apply 19.31. Had to use the “./datapatch -ignorable_errors=ORA-01403,ORA-0651” option
Hi Jeffrey,
thanks – and I know, this is really tricky and annoying 🙁
Cheers,
Mike
The issue is persistent in 19.32 as well.
Did you open an SR?
Then please share the SR number with me. And I guess, you refer to the fallback, right, and not to the “patch up to 19.32”?
Cheers,
Mike