Why Release Update Revisions (RUR) are tricky

A while ago we introduced Release Updates (RU) and Release Update Revisions (RUR). And despite the fact that not only we but also well known external experts such as Ludovico Caldara recommend to stay with Release Updates and simply ignore the Revisions, some people use them. There may be reasons for doing so. But in this blog post I will explain why Release Update Revisions (RUR) are tricky.

Photo by Michał Parzuchowski on Unsplash

Differences between Updates and Revisions?

I tried to explain the differences between Updates and Revisions a while ago – and also compare them to PSUs and BPs.

• Differences between PSU / BP and RU / RUR

And you may please read also this blog post explaining:

• Oracle Database RU and RUR – Recommendations and Facts

But why are Revisions tricky?

Not only I learned recently that some customers got the idea Revisions (RUR) would only contain security fixes. And hence, they decided to stay with Revisions. In a release terminology this means, you’d go from 18.3.1 to 18.3.2 to 18.4.2 to 18.5.2 and so on. This is technically possible.

But it has a very interesting effect you may not have taken into account. Let me show you a quick example.

This is a patching schedule for Oracle Database 18c:

Now we recommend to go forward with Updates (RU). This means you’d apply these patch bundles (or some of them depending on your patch frequency):

But what if you decide to go with Revisions (RUR) instead? Then your schedule may look like this:

Now you may ask yourself: And what is the tricky thing with RURs?

Well, until 18.3.2 everything looks fine as expected. You use:

• The Update (RU) from July 2018 with
• The Revision 1 (RUR-1) from October 2018 containing security and regression fixes from October on top of RU July 2018 and
• Revision 2 (RUR-2) from January 2018 adding security and regression fixes from January on top of RU + RUR-1

So far, so good. But …

With 18.4.2 you don’t add just the security and regression fixes from April on top. This isn’t RU + RUR-1 + RUR-2 + “new security/regression fixes”.

With 18.4.2 you jump now from RU July to RU October. You add all the other content from October – and NOT ONLY the security and regression fixes.

This is important to understand.

And of course, the same jump will happen in July when you go to 18.5.2. Then you introduce the 18.5.0 Update from January automatically.

For me, this is clearly another argument AGAINST using Revisions unless Oracle Support clearly advises you to apply a Revision. You have this hidden jump from one Update (RU) to another. And as you will see this jump anyways, you should go with Updates only. There will be only 2 Revisions – there won’t be an RUR-3. Hence, this jump will happen when you stay with Revisions.

Jan 21, 2020:

An example as addition to clarify in numbers what I explained in graphics above. Let’s take a simple example and say every RU adds 100 new fixes to the previous one, every RUR adds only 25 fixes on top of the RU it’s based on, or the previous RUR. Then it becomes obvious how short-sighted the idea of RURs is. As long as RURs are not given as an emergency but outside-the-schedule bundle on top of a given RU, it makes no sense – and you’ll be hit by what I call the RUR trap or RUR pitfall:

If you follow the RUR track, you will add 100 new fixes with RURs, too, but just delayed by 6 months. I don’t think this makes any sense. And it complicates your patching life as well. And take any example of the above timeline. In October you’d miss 150 existing fixes when you’d stay on the RUR-2 instead of going to the October RU.

Hence, I’m giving you a clear recommendation.

Stay with Updates (RU) instead.
Makes your life much easier.

–Mike