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.




Share this:

12 thoughts on “Why Release Update Revisions (RUR) are tricky

  1. Hi Mike,

    I recently saw an SR (3-18671026781) where support stated that “18.5.0 = 18.4.1 = 18.3.2 will be equal.” which sounded incorrect to me, and sounds different from what you’re saying here. Can you clarify? Am I misunderstanding? Or did support mis-state?


    • Absolutely incorrect – I will follow up with the SR owner.
      18.5.0, 18.4.1 and 18.3.2 will have the same security fixes – and the regression fixes in 18.4.1 and 18.3.2 will be in 18.5.0 as well. But 18.5.0 will have way newer and more fixes than the other two ones. And 18.3.2 is based on the July 2018 RU – but in January 2019 then.


  2. somebodies on oracle support tell to us that ru 18.5 will not be released. i tell to us that in year 2019 will have only 19.2 and that RU 18.4 is the last RU for 18C. It is true

    • Can you tell me the SR number please?
      This is TOTALLY incorrect for on-prem releases.

      The cloud tooling may be different – but the database RU in Jan 2019 will be 18.5.0.


  3. Hi Mike,

    Thank you for this blog post. This topic have been a topic of confusion on my end, and is glad to clear up some of the obfuscations I was unable to totally grasp.
    Are my assumptions correct that the RU’s are also cumulative like the PSU’s are? E.g. We recently updated an 18c DB from 18.3.0 to 18.4.0 without any issues. Would e.g. patching from 18.4.0 to 18.6.0 be possible, if we prefer a 6 month patch schedule for some setups?

    I also assume the RUs would be released as long as 18c is under regular support e.g. RU released in Q4 2020 or Q1 2021 would be 18.12.0?

    • Hi Daniel,

      yes, RUs and RURs are cumulative as PSUs and BPs were before.
      Hence, if you jump from RU 18.4.0 to 18.6.0 you’ll get 18.5.0 plus 18.4.0 and all previous RUs included automatically.

      And regarding release: yes, this is true as well. As long as the release is under bug fixing support.


  4. Hi Mike,

    Thanks for this clarification 🙂

    If I understand correctly, it is still possible to “switch tracks”, as long as you don’t go backwards in the graph. Like the case you mentioned “Oracle Support clearly advises you to apply a Revision” and then you want to get back to applying RU’s only.

    For example: I apply 18.3.0 and Oracle Support (for whatever reason) wants me to apply 18.3.1 next. I can’t go “back” (or rather “up”) to 18.4.0, but I should be ably to get back on the RU track by applying 18.5.0 next. Right? I will skip a separate apply of 18.4.0, but that is included in 18.5.0 anyway, so no harm done there.

    Looking forward to your comment on this.
    Kind Regards,


    • Hi Erik,

      yes, you can switch tracks whenever you want. But as we recommend clearly RUs, there should be no reason 😉
      Technically you “could” even go backwards with a separate home, and when you clean out the higher version at first.

      But you shouldn’t do this as you would lose security content.

      So back to your example:

      18.3.1 and 18.4.0 get released at the same time.
      This means you can use either one and switch back and forth.
      Both have the same security and regression fixes.

      In the next quarter we will release 18.3.2, 18.4.1 and 18.5.0.
      You can switch from 18.3.1 and 18.4.0 to any of them.
      You can also switch between 18.3.2, 18.4.1 and 18.5.0. if desired.

      But YOU CAN’t (technically you could but you shouldn’t) switch from 18.3.2 to 18.4.0.
      In this case you’d go from QUARTER-3 to QUARTER-2 and lose security content, thus making your system afterwards less protected.

      That’s what we don’t want.

      But conclusion:
      Stay with RUs and life’s much more simple


  5. Hi Mike,

    About using Revision patching from 18.3.2 to 18.4.2:
    You wrote:
    “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. Stay with Updates (RU) instead. Makes your life much easier.”

    I understand the hidden jump and I am aware of it. Is there another reason not to use Revisions?
    I ask this, because when I go from 18.3.0 to 18.4.0, I have the same jump but now it isn’t hidden. Therefore there must be another reason, otherwise it wasn’t advised only to use it on Oracle advise.

    How I see it:
    I can better use the Revisions, because 18.4.2 has all the security fixes and urgent updates the same as 18.6.0 and furthermore it has all the fixes from 6 months testing (by customers using 18.4.1 and 18.4.0). In that way 18.4.2 is more stable than 18.4.1 and 18.4.0. Or am I missing the point?

    Otto Edelenbosch

    • Hi Otto,

      very simple – you always hang back – with the 2nd revision you will be behind the RU track by 6 months and miss a lot of necessary patches. That’s why I totally disrecommend the use of RURs unless Oracle Support or the Exadata team advises you to use a specific RUR.

      I see it very differently than you:
      You will hit an issue we fixed months ago and included in an RU. This is bad for you. Bad product experience, Bad situation. Now you need to log an SR to request a one-off based on an RUR. This takes weeks.

      That’s why you should stay away from RURs and go with the current track. And your argument (tested for 6 months) does not count to me as there are thousands of customers who have applied the RU already weeks ago as some have VERY strict patching cycles due to security requirements and audits.


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.