Related Posts on
“The OJVM Patching Saga – and how to solve it“:
- Part I – The OJVM Basics
- Part II – Important Notes and Information
- Part III – The Mitigation Patch
- Part IV – What you may have missed
- Part V – MOS Note explaining “Conditional Rolling Install”
Who’s the Product Manager for Patching?
First of all, I’m neither a patching expert nor am I the Product Manager for Patching. There’s no such role as far as I know but there are people inside Oracle who have way more clue about this topic. There’s a group inside Oracle’s development owning this topic but I’m not working in this team.
Still I’m interested in patching.
Why? Simply because patching goes usually in conjunction with an upgrade or a migration first. Our recommendation for years is this straight forward approach:
- Download and install the most recent release (in most cases the newest patch set which is a full release since Oracle 18.104.22.168)
- Then apply the most recent Bundle Patch (or Patch Set Update) on top
- Then apply the important one-off (single) patches on top (see our slide deck for a guided how-to)
- Then upgrade or migrate
This way you’ll make sure to avoid the most terrible issues known to Oracle already. Of course there’s no guarantee that this will avoid all potential issues and pitfalls. But when dealing with Oracle Support later on (or myself in case we work together on a reference project) it’s much easier for you and us as we won’t waste time to diagnose issues which are already fixed.
Ah, and there’s my background of 6 years of RDMBS mission critical support when I started at Oracle almost 20 years ago.
The OJVM Drama or Saga
Well … procrastination is a terrible but very human habit. The OVJM topic is on my radar for 6 months now. Actually even longer but more and more people approached me in the past months asking so many questions about OJVM patching. And I realized that I don’t have an answer in all cases. As I said above, I’m not a patching expert.
What is this thing I’m calling the OJVM drama or saga? And what the heck is OJVM?
If you don’t have a RAC (Real Application Clusters) system or intend to do Standby-First Patching (see MOS Note: 1265700.1 – Data Guard Standby-First Patch
Apply) you can stop reading here. This “drama” won’t affect you at all.
OJVM is the Oracle Java Virtual Machine which gives you the ability to execute JAVA code directly in the database. The glossary says: “A standard, Java-compatible environment that runs any pure Java application“. If you intend to search for it please use “Oracle JVM” or “JVM” but not “OJVM” as it is not known in the documentation as OJVM.
The saga started actually with the October 2014 PSU (Patch Set Update). It included a patch for the Oracle JVM which required the database to be restarted. And this meant that the patch is not RAC rolling installable anymore.
- PSU October 2014
(Oct 15, 2014)
“Due to the nature of the fixes required, Oracle development was not able to produce a normal RAC-rolling fix for these issues. To help protect customers until they can apply the Oracle JavaVM component Database PSU, which requires downtime, Oracle produced a script that introduces new controls to prevent new Java classes from being deployed or new calls from being made to existing Java classes, while preserving the ability of the database to execute the existing Java stored procedures that customers may rely on.”
Older Blog Posts about OJVM?
Yes of course, I did blog about this already:
- Where it all began – PSU October 2014
- Java in the Database – OJVM non-rolling patches.
- OJVM – Standby-First Patching: Yes or No?
But my focus in these posts is to show you potential solutions and share my experience with workarounds.
So please stay tuned 😉