Certifying an application on a specific RU-only is wrong

Well, there are still 80+ comments I need to answer and reply to on the blog. So please be patient – nothing gets deleted or ignored. But it happens that a topic crosses my inbox, and I need to blog about it right now. Today, it is a case where a customer asked me for advice, and mentioned on the side that they are going to 19.6.0 in OCI. In this relation I’d like to explain why Certifying an application on a specific RU- only is wrong.

Photo by Sigurdur Fjalar Jonsson on Unsplash

What’s the story?

At first, I’m fully aware that some of you will completely disagree with me when you read the headline. But before you vent, please read first.

I can tell the story quickly motivating me to write up this blog post. A customer mailed me with some questions regarding a migration to OCI. And on the side he mentioned that they will go to 19.6.0. In my reply I asked whether this was a typo, and the “1” was missing – which would have meant 19.16.0 instead. But he confirmed that it is indeed unfortunately 19.6.0.

So I went to the coffee machine and brewed myself my morning espresso, scratch my head. And it dawned me where this may come from.

The old days …

In the old days of Oracle 10g, 11g and 12.1 (old days refers to my perception since I deal with 19c and future, but I’m aware that some of you just approached your upgrades to 12.1.0.2 as I learned last week from another customer) you certified an application on a patch set. For instance, Oracle EBS did not get certified on 12.1.0.1 as far as I am aware. The same applies to SAP and many other applications. So when an application was certified on, let’s say, 11.2.0.3, this meant it was certified on a full release.

Then, when you moved from 11.2.0.3 to 11.2.0.4, this was a database upgrade involving downtime. You were using catupgrd.sql or DBUA since those were the old days before AutoUpgrade got born. 11.2.0.4 had significant changes compared to 11.2.0.3 as many of you experienced moving this route.

Now we all agree that an application certification was bound to a database patch set release.

Today and in the future …

But all this has changed with Oracle Database 18c when we introduced the new release model, and with 12.2.0.1 already the new patching model with Release Updates. So while in 12.2.0.1 the RUs added an additional longer number including the date to the release (for instance 12.2.0.1.RU20180722) in 18c this became much easier to digest. 18.16.0 clearly points to RU from a given quarter in a given year.

And certainly, you find the same concept with Oracle Database 19c and Oracle Database 21c. In July 2022 we released 19.16.0, in October 2022 we will release 19.17.0 and so on. Much easier for everybody.

So where’s the glitch?

The customer’s statement made me think. Why would one certify an application on 19.6.0? This makes no sense to me.

I know that some of you will disagree but keep in mind that the new features we rolled out such as blockchain tables in 19c RUs require a COMPATIBLE change which we disrecommend to do when you patch for many reasons. Hence, an RU should not involve any functionality change. Of course, there are a lot of fixes in an RU, and we all know IT too well to not being skeptical when you pack 7000+ fixes together that it may not cause one or the other regression. We all know by experience that this happens from time to time. And no discussion, this is frustrating for you but for us as well despite the efforts to improve quality.

Still, in my opinion, you should never certify an application on a given patch level only.

When you compare the old and the new release model, it boils down to me to:

• 11.2.0.3 => 11.2.0.4 … this was a patch set upgrade and you must re-certify your application … it is the same as in the new release model when you move from 18.13.0 => 19.16.0 – then you upgrade, you have downtime, you will re-certify your application certainly
• 11.2.0.4 PSU 20180119 => 11.2.0.4 PSU 20181021 … this is a patch operation, not an upgrade – and you never certified your application again for the new PSU. Of course, you did basic functional testing most likely, and you certainly did some performance testing and checks. But you didn’t ask the application to certify again for the new PSU. I guess you don’t certify again when you apply the 19.15.0 RU to your 19.13.0 database environment, right?!

I think this is where the glitch happens – the “new” release model which is now around for more than 4 years leads to this misunderstanding.

If I’m wrong with my assumption, or if you solidly disagree with me, please use the comment option and be patient (see above – 80+ comments to work on before keeping me busy).

But when I look at our own applications such as Siebel or EBS or PeopleSoft, they are certified on 19c or 12.1.0.2 – but not on a given RU or PSU. The same applies to SAP and others. Of course, vendors may give recommendations for certain patches. This makes sense. Or decide that a given patch is a requirement to be applied.

My summary

Certify your application on the base release such as 19c. Or if you intend, do the first certification on a given RU and make this the minimum RU such as “Our application requires at least Oracle Database 19.12.0”. But don’t make this an exclusive statement such as “Our application requires Oracle Database 19.12.0” since this makes no sense to me.

Certify on a base patch level, make this the entry requirement – but allow RUs to be applied on top by saying or writing something such as “Our application requires at least Oracle Database 19.12.0 – or newer”.

And don’t go live in 2022 on 19.6.0 – you will regret it. I bet a good decent bottle of LBV Port that you’ll find yourself patching to a much newer RU just a few days after go-live. Trust me. You miss 6721 fixes, no joke!

–Mike