On February 3rd, 2026, I was reminded of a scene from ‘Back to the Future’. Towards the end of the movie, a panicked Doc Brown steps out of his DeLorean with a warning that something in the future must be avoided at all costs. I felt that same sense of urgency when I found out that the Oracle Database 19c 19.30 Release Update (RU) had been released and then withdrawn almost immediately due to a critical bug.
The bug in question is bug 34352668, which impacts only Oracle Real Application Cluster (RAC) database systems (more on that in a moment). What is even more concerning is that this same bug was apparently present in the October 21, 2025, Database RU (19.29) as well. You can find more detailed references to this problem from Mike Dietrich (Oracle VP) here.
What is the impact of the bug that was present in the Oracle database 19c RU?
Here are the quick highlights with respect to the bug:
- Only Oracle RAC environments are impacted
- This bug only appears to impact RAC environments that are involved in rolling upgrades
- The bug exists in both RU 19.29 and RU 19.30
- The potential impacts of this bug include block and redo log corruption
It’s concerning that this problem, which is confirmed to be present in RU 19.29, didn’t appear to be discovered until RU 19.30. Oracle has provided several workarounds and patches to address the myriads of problems that might arise if someone has already applied RU 19.29 or 19.30. Of course, these workarounds and patches cannot recover any already lost data — only a sound backup and recovery strategy can do that.
“Great Scott!” Doc Brown said. But wait, there is more.
A 9% patch failure rate isn’t a winning strategy
Unfortunately, this withdrawal isn’t an anomaly. It follows a concerning pattern in Oracle’s RU patching history, particularly for RAC customers.
- Oracle released the January 2023 19.18 RU, only to discover that it too had a bug in it that impacted clients that were running Oracle RAC. As with RU 19.30, Oracle quickly removed 19.18 to fix the problem. Upon re-releasing the newly “fixed” RU, Oracle had to quickly pull it again due to issues with its repackaging. Oracle finally provided a corrected version of the RU on January 31, 2023. There is a pretty good explanation of this debacle here.
- Oracle released DB RU 19.3.0 on January 31, 2023, only to pull it back again due to regressions contained in the RU. Notably and confusingly, they fixed the RU and released it as RU 19.3.1. You can read about this regression here.
This does not seem like a successful result and by ‘successful’, I mean RUs that were not withdrawn, reissued or superseded due to serious regressions shortly after release.
A total of 27 Oracle Database 19c RUs have been released (starting with RU 19.3 and ending with RU 19.30). That’s 27 RU patch sets deployed with a deployment failure rate of 9%. For mission-critical enterprise software, that’s not acceptable.
Look, I’m a pilot. In fact, I live in an airport with my airplane just a few steps away. If my airplane had only a 91% success rate across 27 flights, I’m pretty sure I’d not be flying it.
In short, this patch release failure rate shows that patching can sometimes lead to instability, unplanned outages and potentially significant operational risks. If, on a macro level, freshly deployed patches have had a 9% failure rate out of the box, what do you suspect the actual overall failure rate must be on a more micro level?
At Rimini Street, we often see ticket counts go up when our new clients apply vendor patches from their archives. Then, slowly, after the clients have stopped applying patches, we see their systems stabilize along with ticket counts. This is why we work hard to educate our clients on what I call the, “no patching paradigm.” (read on to learn more!) Although routine patching is strongly recommended by ERP vendors, it can cause disruption or instability when not executed properly.
The security angle
Even if we accept disruption as the cost of patching, security presents an even bigger problem. The withdrawal of any RU also means a delay in applying the latest security patches. This just compounds an already problematic security patching cycle. These days we have zero-day threats popping up on a real-time basis. Any vulnerability that is publicly disclosed today could have been in the process of being exploited before it became a CVE or could be patched.
The patching paradigm doesn’t address this kind of vulnerability latency. We need a way to minimize the security risk overall, and Rimini Street has security tools to help with that.
The solution is Rimini Street
Doc Brown might well have looked at the problem and said, “Patches? Where we’re going, we don’t need patches.”
The solution to manage risk and improve operational availability is to move away from the patching paradigm. Certainly, you will still need support, and you will run into an occasional problem that you need help with, but these problems can be addressed tactically and in ways that mitigate risk to your key business systems. That is the Rimini Street way, and it’s worked for thousands of clients for over 20 years now.
Key takeaways
For Oracle environments, the growing complexity and operational risk associated with quarterly RUs, and the potential for withdrawn of reissued updates, has reinforced the limitations of a patch-dependent security model.
Rimini Street and our proven third-party support solutions have demonstrated for over 20 years that the patching paradigm can be replaced by a methodology that minimizes risk by providing targeted fixes to problems when they do arise.
When there is a problem, we use root cause analysis. Once the problem is identified, experienced ERP engineers craft a targeted alternative solution and implement it with minimum interference to the rest of the system.
Rimini Street provides a suite of advanced security solutions with Rimini Protect™ for Oracle. These solutions help reduce the time required to protect your database assets against newly developed exploits. These tools also work to reduce the impact that security monitoring and protection have on your key business systems.
Our Advanced Database Security Suite provides a more resilient alternative. It is purpose-built to improve security postures and reduce security risk exposure. It does this without modifying vendor code, and when vendor-provided security patches are not available, it helps protect against active exploits.
Our solutions are tailored to a client’s ecosystem to complement and enhance their existing security strategies, protecting against discovered and undiscovered or zero-day threats and vulnerabilities. The Rimini Street approach reduces exposure by addressing problems tactically, without introducing a broad set of untested changes into a stable environment. In short, let’s take Doc Brown’s DeLorean into the future and leave the past behind.
