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

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.

And you may please read also this blog post explaining:

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:

Why Release Update Revisions (RUR) are tricky

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):

Why Release Update Revisions (RUR) are tricky

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

Why Release Update Revisions (RUR) are tricky

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.

Why Release Update Revisions (RUR) are tricky

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.

Why Release Update Revisions (RUR) are tricky

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.

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

–Mike

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required

*

I agree

This site uses Akismet to reduce spam. Learn how your comment data is processed.