Many of you mailed us asking why AutoUpgrade does not download 19.29 or 19.30 RUs anymore. Others just noticed that the RUs got pulled without further communication visible. And a few people informed me about an issue with the 19.30 RU when you don’t have OJVM configured but install the OJVM bundle. So, what has happened to the 19.29 and 19.30 RUs??
Photo by Lukas Seitz on Unsplash
Release Update 19.29 and 19.30
A fix for Bug 34352668 – LNX64-23.1-RAC: SVCB HIT ORA-600 [KCBGTCR_17] has been included into RUs 19.29 and 19.30 but unfortunately it could potentially cause a regression.
The topic is described well in KB867473: Fix 34352668 in 19.29 and 19.30 DBRU May Cause Corruption in Primary Database and Redo Corruption Impacting Standby Recovery.
Several people asked me already whether they’d be affected since they are not doing rolling patch upgrades. Some even speculated that it will affect them when they use standby-first patching, or only when they are using a transient logical standby.
So, let me put together a short description from my point of view.
As written above, the fix for Bug 34352668 caused a regression in RUs 19.29 and 19.30. KB867473 gives an explanation:
In 19.29 DBRU, Bug 34352668 can disable RAC lock state error handling on some instances during a rolling update. In certain Global Cache hang scenarios, this may create lock state inconsistencies and, in rare cases, cause block corruption.
According to oradiff.oracle.com this bug fix causing the issue has been shipped in 19.29 and 19.30.
Why did it hit right now?
You may wonder why it has been found right now, months after 19.29 got released in October 2025?
I guess the simple explanation is that many of you patch n-1, meaning you are going to apply 19.29 once 19.30 got released in January 2026. These was the MAA recommendations for many years (but it may change soon), and exactly in such environments many of you are having RAC environments, whether on Exadata or on non-Exadata systems.
Could you be affected?
In summary, not many of you could be affected by this issue.
- The issue affects only those who do RAC rolling updates, meaning, you apply the Release Update 19.29 or 19.30 in a rolling fashion
- In rare cases, it could lead to block corruption but only when you do RAC rolling updates
- It did not affect standby-first patch apply
- It did not affect Transient Logical Standby updates if there is no RAC rolling patching done
- It did not affect regular single instance patch apply
- It did not affect your Grid Infrastructure installation
- It did not affect your client installations
I am just listing all these cases to be extra-clear since I received so many different questions.
We decided to pull the Release Updates 19.29 and 19.30, and disable the fix for bug 34352668 in the RUs.
How do you solve it?
Since many of you have realized, the 19.30 RU already got re-uploaded with the issue being fixed. The 19.29 RU remains password protected to prevent you from hitting the issue.
There are several ways to tackle this issue.
Use the re-uploaded 19.30 RU
- Use the Release Update 19.30 which had been re-cut and re-uploaded on February 2
- Database Release Update 19.30.0.0.260120 PATCH 38632161 for UNIX
- Database Bundle Patch 19.30.0.0.260120 PATCH 38597735 for Microsoft Windows 32-Bit and x86-64
Apply a one-off before you patch RAC rolling
In case you’ve installed the early 19.29 or 19.30 RUs, there is a one-off Patch 38854064 (RAC rolling-installable; not online patchable) available already to solve the issue. You only need to apply it on to if you didn’t use the re-uploaded RU from option 1.
And really important …
Please pay close attention and read (KB867473) Fix 34352668 in 19.29 and 19.30 Database RU May Cause Corruption in RAC Databases and Redo Corruption Impacting Recovery carefully. There are various way to mitigate this issue, and since all of them are covered in full detail in KB867473 it makes no sense for me to repeat them.
Please read KB867473.
A short clarification on how the issue is fixed
Somebody commented on how the issue is fixed. Therefore, let me clarify this. As I wrote above, the issue is introduced with the fix for bug 34352668 which is in 19.29 and 19.30. In 19.30 in the revised version of the RU, another fix got added:
KB867473 is not precise here and states:
The 19.30 Database and Grid Infrastructure RU Patches […] have been recalled and replaced as of Mon 02-Feb-2026 with an updated version that does not contain the regressed fix 34352668 originally included as part of 19.29 Database RU.
So, for your understanding, the fix for bug 34352668 which caused the regression got backed out with the newly included fix 38884142. But the fix for 34352668 is still part of the RU but the fix for 38884142 “corrects” it.
You can verify this in oradiff since both, the pulled version of 19.30 and the newly added version of 19,30 show the difference.
oradiff showing the fix difference between the pulled 19.30, and the new 19.30 Release Update
In the cloud?
Please be aware that you must use a separate MOS note (KB868434) Potential Database Block Corruption in Oracle Database Cloud Service (RAC with DB RU 19.29): Risks and Mitigation Strategies with explanation and instructions for cases where you run in the cloud.
Password-protected 19.29?
The reason why 19.29 GI and DB RUs are still password protected is easily explained. At first, the GI RU contains the DB RU as well, and the DB RU contains the issue and requires the extra fix. Furthermore, we think that you should move to 19.30 instead. Therefore, only if you really really really need 19.29, you need to open a ticket and ask Oracle Support for the download password. Then you can fetch it.
Initially, 19.30 was missing in (KA958) Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases. But the owner has added it on Monday, and the change got approved on Tuesday this week. Hence, you should be able to see it there now.
AutoUpgrade patch download fails?
We were overwhelmed by the feedback we received that
- AutoUpgrade did download the 19.28 RUs instead of 19.29 or 19.30
- AutoUpgrade still does not download 19.29 RU
- AutoUpgrade fails to download 19.30 RU after 19.30 has been re-uploaded
(a) and (b) did happen, because the RUs got pulled, and 19.29 was or still is password-protected.
But most importantly, (c) got fixed on Saturday with a new version of AutoUpgrade (26.2). I will explain in another blog post what the reason was/is, and what else the new AutoUpgrade is able to do for you to ease your patching life.
Please download the newest AutoUpgrade 26.2 from MOS Note: KB123450 – AutoUpgrade Tool.
Further Links and Information
- (KB867473) Fix 34352668 in 19.29 and 19.30 Database RU May Cause Corruption in RAC Databases and Redo Corruption Impacting Recovery
- (KB868434) Potential Database Block Corruption in Oracle Database Cloud Service (RAC with DB RU 19.29): Risks and Mitigation Strategies
- Patch 38854064
- (KB123450) AutoUpgrade Tool
- (KA958) Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases
–Mike
Dear Mike,
I think this info could be useful for our community. So recently I noticed/confused that the re-released 19.30 still contains 34352668 and immediately opened a SR to Oracle:) And here is answer:
—-
Hi Team,
We have reviewed and verified the details. It is expected.
The Bug 34352668 – LNX64-23.1-RAC: SVCB HIT ORA-600 [KCBGTCR_17] is part of Release Update patch.
and the below tracking bug 38884142 also part of RU.
Bug 38884142 – TRACKING BUG FOR THE BACKOUT OF BUG 34352668 LNX64-23.1-RAC: SVCB HIT ORA-600 [KCBGTCR_17]
And since you are applying the re-released GI / DB RU patch,we do not have actions required or steps to be performed.
—
Cheers, Nariman
Thanks – and yes, this is how it works.
The fix is NOT removed but instead a fix is added which disables the fix which caused the regression.
Thanks for pointing this out.
Cheers,
Mike
Hi Mike,
Thanks for the clarification. Let me specify my case.
I’m currently preparing a new AIX-based RAC environment. As you know, the 19.30 RU for AIX has not yet been released. I attempted to download the 19.29 GI RU, but it turned out to be password‑protected. Since I cannot wait for the 19.30 RU availability, I opened an SR to request access.
Oracle Support did not provide the password. Instead, they uploaded the patch to OCI Object Storage and shared a direct download link. Unfortunately, they did not address my original question regarding the reason for restricting access to 19.29 RU, nor did they confirm whether any known issues exist with this release.
To summarize:
The 19.30 RU for AIX is still unavailable.
The 19.29 RU is password‑protected and not accessible via standard MOS channels.
Applying 19.28 RU is possible, but it leaves the environment at the (N‑2) release level. 🙂
Hi Igor,
I was not aware that the GI patch has been password protected as well – makes zero sense to me, and I flagged this internally to the people in charge as well.
No idea why the engineer did not give you the PW. That is a standard procedure.
For 19.30, please see:
https://support.oracle.com/support/?anchorId=&documentId=CPU4&page=sptemplate&sptemplate=km-article
Section 2.2: Post Release Patches
Scroll down a bit, then you’ll see that database and GI 19.30 is going to be available by Feb 14.
Thanks
Mike
The GI RU contains the DB RU. That could be the reason why GI RU is password protected as well.
You know things so well, Andreas – and this is exactly the answer I received yesterday when I did ask the person in charge.
There, yes, and thank you. The reason indeed is that DB is packaged with GI.
Thanks,
Mike
Perhaps this is because the DBRU is included in the GI patch? When I apply the GI patch with opatchauto it will automatically apply the DBRU to any registered DB homes as well.
Cheers,
Tony
Correct – as Andreas commented as well already, you both were right – that it fact is the reason.
Thanks for adding this – cheers,
Mike
It is Feb 16 and GI 19.30 is not available. The release is postponed again. We are dissapointed by “promissing” Oracle policy in recent years.
I feel sorry – but there is nothing I can do here.
Please get in touch with your Oracle contacts and tell them.
Thanks,
Mike
Hi,
I’ve also been trying to install AIX with the latest RU.
Using Autopupgrade with the option
upg.patch=recommended.
shows that 19.28 is being downloaded.
However after installation the RU installed turns out to be an 19.29:
Download:
————————————
Downloading files to /opt/repd01/exp
————————————
DATABASE RELEASE UPDATE 19.28.0.0.0
Installation:
+—-+————-+———–+———+——-+———-+——-+—————————————-+
| 100|create_home_1|OH_PATCHING|EXECUTING|RUNNING| 11:36:56| 9s ago|Database Release Update : 19.29.0.0.2510|
+—-+————-+———–+———+——-+———-+——-+—————————————-+
The issue is/was caused by the fact that the initial RU of July-2025 was still residing on the file system from which we do the installation.
So Autoupgrade seems to be a bit confused in what needs to be done. Recommended download seems to be different from recommended installation.
Hi Frank-Jan,
let me share this with the team.
Thanks
Mike
Actually, let me try to understand at first.
1. You used AU for download for AIX with RECOMMENDED
2. It fetched and downloaded 19.28 (19.29 is password protected, and I fear that 19.30 is not available on AIX yet) – then this is correct
3. Now you had 19.29 from October in the download folder as well
4. You asked AU to install from this folder
5. It installed 19.29
If this is the case, then this is expected since 19.29 is the newest, and AU will automatically pick the newest available RU.
But please share more details with me.
Cheers,
Mike
Hi Mike,
Thank you for the answer, your spot on in what happened.
What details will help here, shall I zip you the logs?
Thank you
Frank-Jan
Yes, I will need the logs, please.
Thanks
Mike
Hello Mike,
In the chapter “Apply a one-off before you patch RAC rolling”…..
“In case you’ve installed the early 19.29 or 19.30 RUs, there is a one-off Patch 38854064 (RAC rolling-installable; not online patchable) available already to solve the issue. You only need to apply it on to if you didn’t use the re-uploaded RU from option 1.”
You write that we can simply apply the latest 19.30 patch.
However, in the next chapter – Oracle’s official KB article:
“And really important …”
Oracle writes that you always have to apply the one-off?
For us, the big question now is: do we need this one-off or not if we apply the latest 19.30 patch?
Hi Manuel,
no, you only need the one.off if you took the early 19.30 or 19.29 – 19.30 got recut and the offending fix got disabled.
Thanks
Mike
Hi Mike,
Currently on 19.29 Linux 86-x64, Exadata RAC.
Please advise, so there is no mistake here, regaring below “apply” with immediate “rollback” of 38854064 while patching to re-released 19.30 ?
Also, alter system set + reset right away ? Kind of back to where it was?
Thanks,
Serg
[KB867473]
“Case 3.1: Already running on 19.29 Database RU
Any Instance on 19.29
SQL> alter system set “_gcs_recoverable_asserts”=3 scope=both sid=’*’; alter system reset “_gcs_recoverable_asserts” scope=both sid=’*’;
Part 1: Apply Patch 38854064 on 19.29 Database RU
…
Apply Patch 38854064 to the 19.29 Database RU home in a RAC
…
Part 2: Update to 19.30 Database RU
Rollback 38854064 (19.29)
Apply the 19.30 Database RU patch
Re-apply one-off 38854064 (19.30)
…
“
Hi Serg,
sorry, I totally missed your message – is this question still open?
Thanks
Mike
Hi Mike,
You haven’t mentioned the cause of OJVM bundle install issue. Is it fixed in latest release of 19.30?
No, and this is something I have on my list for this week.
I didn’t want to overload the blog post with too much information.
Thanks
Mike
Because GI RU includes the RDBMS Patch (for the GI Oracle_Home) so the GI RU released earlier may have the older RDBMS patch files.
Even if it doesn’t cause corruption in the database, their could be differences in the RDBMS library files between the two Oracle_Homes if the earlier release of the GI RU and the latter release of the RDBMS RU are used.
My suggestion would be to download both the new (02-Feb release) GI and RDBMS RU
Absolutely!
Cheers,
Mike
Hi Mike,
I have RAC on 19.29 (19.29 Database RU + 38854064), the KB article says to apply 19.30 we need to rollback 38854064 and apply the 19.30 then re-apply 38854064. I have downloaded the latest 19.30 released on 02 Feb. Do I still need to perform these steps ?
Thanks
Hi Muhammad,
no, of course not – the MOS note may be a bit imprecise. When you have the NEW 19.30 RU, then all is fine.
Mike
Hello Mike,
We are currently running on early Oracle Database Release Update (RU) 19.29. The following parameter changes were executed across one RAC database instance:
ALTER SYSTEM SET “_gcs_recoverable_asserts” = 3 SCOPE = BOTH SID = ‘*’;
ALTER SYSTEM RESET “_gcs_recoverable_asserts” SCOPE = BOTH SID = ‘*’;
In addition, Patch 38854064 has been successfully applied.
We are planning to upgrade our RAC database to the latest Oracle Database RU 19.30. The proposed approach is to perform an out-of-place upgrade for both Oracle Grid Infrastructure and the database home, using SwitchGridHome for Grid Infrastructure and runInstaller.sh followed by a database restart for the database home. We intend to carry out the database home software upgrade in rolling mode across the RAC nodes.
Our questions are as follows:
Is it advised to apply Oracle Database RU 19.30 using an out-of-place, rolling patching approach in an Oracle RAC environment? because the document(KB867473) does not mention anything about out-of-place patching. there are some restriction mentioned in the document regarding database restart and rolling patching database homes
Are there any specific precautions or prerequisite checks we should be aware of before proceeding with out of place patching to 19.30 RAC rolling approach?
Is this approach considered safe and recommended for a production RAC database?
We would appreciate your guidance and confirmation.
Thank you.
Hi,
yes, Daniel has a great series of blog posts about GI patching, and we recommend out-of-place generally.
https://dohdatabase.com/2023/02/15/how-to-patch-oracle-grid-infrastructure-19c-using-out-of-place-method/
Cheers,
Mike
Hi Mike!
Our biggest problem was actually the issue with applying the OJVM patch in environments without the Java option enabled in the database! You mentioned it “with the 19.30 RU when you don’t have OJVM configured but install the OJVM bundle” but then didn’t address it in the blog, or am I overlooking it? We also had to install “38844367 – 19.30 OJVM PATCH APPLY IS FAILING ON SECOND NODE IN RAC ENVIRONMENT WITH ERROR IN JAVAVM/INSTALL/BUG35933540_APPLY.SQL FILE,” even though we don’t have a RAC in use.
Hi Dirk,
I am writing this blog post right now – should be out there tomorrow since many others have been trapped by this as well.
Sorry for the inconvenience
Mike
You mentione troubles with OJVM patch without OJVM – it is 38844367 (19.30 OJVM PATCH APPLY IS FAILING ON SECOND NODE IN RAC ENVIRONMENT)
Unfortunately, when I try to rollback, datapatch crashes even with this patch. But that’s not a very common scenario.
Hi Pavel,
I will try to cover this for my blog post for tomorrow. There will be a w/a customers shared with me.
Thanks, and sorry for the inconvenience
Mike
Hi Mike,
Tnx for all your work. I can’t find anywhere is Rac 1 Node affected by this issue?
Tnx,
Vlada
Hi Vlada,
only when you do RAC Rolling Patching, which requires more than 1 active node.
Cheers,
Mike
Hi Mike,
I would think, 19.30 should be available everywhere meanwhile, but it is not on an oracle@AWS exadata! I can only update GI to 19.29 or 26.* there. Is there still some issue with the RU? I hope you can answer ;-).
Regards,
Robert
Hi Robert,
I fear that it usually takes some weeks until the RUs appear in the cloud deployments as well. Since 19.30 is pretty “new” it should not take too long but I have no exact timing.
Cheers,
Mike
Hi Mike, I noticed that since March 4th, rel 19.30 has also been present in the cloud. Has it been fixed? Or is the bug still present?
Marco,
I can’t really say but I guess this has been fixed since this was considered a significant issue.
Cheers,
Mike
Thanks a lot Mike and all who contribute! But wanted to ask if anybody still have problems downloading the 19.30 RU? I need it for AIX 64 bit but tried it also for other platforms and still get the error:
400 Bad Request
Request Header Or Cookie Too Large
Hi Jose,
please be a bit more specific:
Are you downloading it manually, via the browser, or with AutoUpgrade?
Thanks,
Mike
you need to delete the browsing data (history, cookies, cache) and then you should be ok
SR indicated that 19.30 will be skipped on OCI.
Their plan is to wait for 19.31 RU.
Just a FYI on Oracle Support reply as I inquired where is 19.30.
Might want to Notify Users that this will effect..
Thanks for the update, Mike!
Mike
Hi Mike,
our process involves creating a new ORACLE_HOME to perform out-of-place patching.
We have the ORACLE_HOME running on 19.29 and the one we are preparing with the new 19.30 + recommended one-offs.
In support note KB867473
“Case 3.1: Already running on 19.29 Database RU”
specifically states that certain steps must be performed.
From what I understand from the KB, these steps are only to be performed if the ORACLE_HOME patching is done in-place.
So if we set up the new ORACLE_HOME and move the database, do we have to follow the steps in the KB for ORACLE_HOME 19.29?
Or should we do it this way:
1. Set and reset the _gcs_recoverable_asserts parameter
2. Shut down database instance 1
3. Patch GRID to 19.30
4. Move the DB to the new ORACLE_HOME 19.30
5. Repeat steps 2 through 4 on node 2
6. Datapatch
Is this approach/procedure correct?
Thank you
Stefano
Stefano,
apply the patch instead, or use 19.30.
Cheers,
Mike