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.
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:
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
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?
Thanks,
stephan
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.
Cheers,
Mike
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.
Cheers,
Mike
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.
Cheers,
Mike
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,
Erik
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
Mike
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?
Regards,
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.
Cheers,
Mike
Hi Mike,
Thanks for the clear description why the RU track gives us a much better experience (more bugs fixed).
We switched now to the RU track approach.
Regards,
Otto Edelenbosch
Perfect – and thanks for your reply, Otto!
Cheers,
Mike