Since Oracle Database 12.2.0.1 we change our patching model as well, switching from Patch Set Updates (PSU) and Proactive Bundle Patches (BP) to Release Updates (RU) and Release Update Revisions (RUR). But what are actually the differences between PSU / BP and RU / RUR patch bundles? Is there any or is it just a renaming of well known patch bundles?
No change on MS Windows
First of all, let me say that there won’t be any changes on the Windows platform. If your preferred operating system is MS Windows then stop reading here. On Windows you’ll see exactly the same patching format with Bundle Patches as you saw before.
How about the other platforms?
Everybody else will see changes with Oracle Database 12.2.0.1 – and I blogged about it a while ago:
- PSU or BP? Patch Set Update or Bundle Patch? RUR or RU? (May 12, 2017)
- More Information about RU and RUR patches for Oracle 12.2 (Jul 19, 2017)
- Applying the first RU to Oracle Database 12.2.0.1 (Jul 20, 2017)
- Download Assistant for RUs, RURs, BPs, PSUs, Patch Sets and Releases (Oct 13, 2017)
- Are OJVM patches included in the Oracle 12.2 RU / RUR (Oct 20, 2017)
As I presented now about the first release model already at a User Group Conference I have had some discussions already about RU and RUR – and I believe there’s a bit more clarification needed.
Differences between PSU/BP and RU/RUR
In July 2017 the first Oracle Database 12.2.0.1 RU became available, since October the second RU and the first RUR are available.
But there’s a significant difference between PSUs and RURs. Even though we say “RURs replace PSUs” RURs are not the same as PSUs.
When you look at the PSU and BP trains before you usually choose at the entry to a release which path you’d like to follow, either PSUs every quarter, or BPs. Engineered system customers had no choice: it was Bundle Patches. In Oracle 11.2. the BPs were meant only for Engineered-systems environments. In Oracle 12.1 we switched and recommended BPs over PSUs for all systems.
Patch Set Updates And Bundle Patches
A Patch Set Update (PSU) contains usually security fixes and regression fixes, i.e. bug fixes.

Typical Patch Set Update (PSU) – quarterly
Whereas a Proactive Bundle Patch (BP) was a superset of a PSU containing the PSU but optimizer fixes and functional fixes which may be sometimes feature extensions as well.

Typical Bundle Patch (BP) – quarterly released
And you choose either one train usually. But you could also change from PSUs to BPs or vice versa. Your flow would actually look like this:

Quarterly Patching with either PSUs or BPs – every quarter gets new fixes, PSUs and BPs, each are cumulative to themselves
As PSUs and BPs, each are cumulative you’ll get the fixes from all previous PSUs or BPs for the same release included as well. The PSU a quarter later has new security fixes and new regression fixes added, the Bundle Patch in addition gets new optimizer and functional fixes and of course the same new security and regression fixes the PSU has gotten.
Please see MOS Note: 1962125.1 – Overview of Database Patch Delivery Methods for further details. Optimizer fixes are off since we introduced the FCP (Fix Control Persistence framework) with DBMS_OPTIM_BUNDLE.
Release Updates
Release Updates (RU) look pretty similar to Bundle Patches (BP):

The first Release Update (RU-1)
The following second Release Update contains everything from Release Update 1 plus new fixes in all four areas (marked in dark red/purple below). RUs are cumulative as well as the BPs were.

The second Release Update (RU-2)
RUs get released quarterly at the usual dates.
Release Update Revisions
A Release Update Revision (RUR) is different from an PSU. At the time of the release of RU1 there won’t be an RUR yet. The first RUR will be released containing the entire first RU – plus additional fixes on top. Regression fixes are fixes for misbehavior. They usually hit a lot of customers.

First Release Update Revision (RUR-1)
Actually the first RUR will be released usually a quarter after the first Release Update (RU). It will include all fixes from Release Update 1 (RU-1) – and add only new security and regression fixes on top. But no new optimizer or functional fixes. When you compare it with the picture above (“The second Release Update”) you’ll spot the same security and regression fixes.
At this date you will have the choice now:
- Use the Release Update Revision (RUR-1)
or:
- Install the new Release Update (will be RU-2 by then). It contains the same security and regression fixes as the RUR-1 but also new optimizer and potentially functional fixes in addition (see the picture of “Second Release Update (RU-2)”.
3 months later the next RUR will be released – and it will contain now again only the new security and regression fixes (marked in turquoise) on top. There won’t be any new optimizer or functional fixes added at this point. When you compare both pictures, the one above and the one below (RUR-1 and RUR-2) you’ll see the exact same optimizer and functional fixes from the initial RU-1.

Second Release Update Revision (RUR-2)
And at the same time the third Release Update (RU-3) will become available as well.
It’s important to mention that there is no third Release Update Revision (RUR-3) planned. The model allows only 2 RURs per RU. Afterwards you have the option to either get the most recent RU – or an RUR based on an older RU.
Overview – The Big Picture
The full picture summarizes the schema:

Overview on Release Updates (RU) and Release Update Revisions (RUR) over time
Now you see why there is a significant change. There’s no such thing as PSUs anymore. And you are not nailed on a track. You have the choice to either progressively step forward by applying Release Updates – or pause with new optimizer and functional fixes for up to 6 months patch period.
–Mike
Many thanks you for clarify. It’s not so easy to understand.
May I ask anything else: what are “Mitigate” patches? I’ve read in conclusion with OJVM patches
Best regards
Peter
On the blog, Peter 🙂
https://mikedietrichde.com/2016/09/14/the-ojvm-patching-saga-and-how-to-solve-it-part-iii/
Cheers
Mike
Mike,
I’m trying to understand what is the best way to receive the optimizer fixes with the latest RU/RURs. Even after I apply the latest RU or RUR, the optimizer fixes are disabled by default. How do I know what fixes were included and how do I decide which ones to turn on or leave off. I think there needs to be some clarity around this.
From a customer point of view, if I’m applying a latest RU, I’m hoping to get all the fixes (including optimizer fixes) with the patch. In my experience, most of the issues around the upgrades, are around the optimizer !
Thanks
Naveen,
I know that this is a strange topic. But in fact I tried to clarify this more here:
https://mikedietrichde.com/2017/11/07/ru-rur-recommendations-facts/
Please check the RU’s readme. If it DOES NOT contain this paragraph:
“This patch introduces fix control for one or more fixes contained herein. These fixes are disabled by default and will have to be explicitly enabled via alter session/system commands to persist in pfile/spfile as appropriate”
then no BEHAVIOR CHANGING OPTIMIZER fixes are included and thus nothing to switch on. As soon as this paragraph is present in the RU’s readme there will be guidance which _fix_control setting needs to be used in order to enable the fixes.
In the July and October RU for 12.2.0.1 there are no such fixes as far as I can see.
Cheers
Mike
Hi Mike,
some of the images are missing in this article, could you pls re-publish the page with the images loaded properly
Ammar,
are you sure? I tried different browsers and for me all the pictures get displayed correctly.
Can you please check again and maybe hold the SHIFT key when you push RELOAD in your browser (than it should fetch images again).
THanks,
Mike
Hi Mike
as everytime thank you
Maybe I’m confused but the last your pitcure (in the box B-2 🙂 ) seems you are writing that is possible to apply RUR-1 on RU-2 , but before you write “Install the new Release Update (will be RU-2 by then).It contains the same security and regression fixes as the RUR-1 ..” And I undestand that RU-2 include RUR-1 …
Thank you
Luca
Hi LUca,
I know this is a bit confusing – and another reason why I disrecommend to touch RURs unless you get a clear advice from Support or the MAA/Exadata team.
Let me explain this with months – I think then it is less confusing.
Example:
– in January we release 18.1.0 – no RU or RUR available
– in April we release 18.2.0 – and for the initial release (18.1.0) there won’t be any RUs or RURs
– in July we release 18.3.0 (RU and on-prem base release) and 18.2.1 (RUR-1 on top of 18.2.0)
Both, 18.3.0 and 18.2.1 have the same security and regression fixes. But 18.3.0 has more additional fixes and behavior changing optimizer fixes turned off by default.
– in October we release 18.4.0 (RU), 18.2.2 (final RUR for 18.2.0) and 18.3.1 (first RUR for 18.3.0)
All contain the same security and regression fixes. But they settle on different RUs meaning the amount of fixes is very different
In theory you could switch technically between all 3 of them. But let’s say you give 18.4.0 a try and decide later to roll back to an older patch, you could go backwards to 18.3.1 and 18.2.2 having the same security and regression fixes but missing a lot of additional fixes your release had already consumed. This is technically possible but not recommended.
When I write RU-2 contains the RUR-1 that means that RU-2 has the same fixes as RUR-1 delivers – but more.
This is credited to the fact that RU-2 contains:
– RU-1 (<== e.g. July) - The security and regression fixes from October - Extra fixes such as optimizer behavior changing fixes off by default And when you compare this to RUR-1 which gets released at the same time, it contains: - RU-1 (<== e.g. July) - The security and regression fixes from October That's why I wrote: RU-2 includes RUR-1. Hope this helps - cheers, Mike -
Hi Mike,
Thanks for your article.
I would like to know the differences between regression and functional fixes.
I could guess but I’d rather be sure.
My client traditionally applies a patch policy consisting of applying interim patches because he fears bugs caused by Patches (PSUs and BPs before, RUs and RURs now). He would be comfortable applying patches with only security bugs … I think the most similar approach would be applying RU and all the RURs of this RU until the next RU.
Thank you,
Jorge
Jorge,
I was trying to find the relevant MOS note explaining the differences between regression and functional fixes but was unable to find it.
You client must change the policy. First of all, there are no bundles containing security fixes only. And second, there are no PSUs anymore.
Release Updates are the same as Bundle Patches. And stay away from Revisions unless Oracle Support ask you specifically to apply a Revision – see here, why you (or your client should stay away from it):
https://mikedietrichde.com/2018/11/08/why-release-update-revisions-rur-are-tricky/
Cheers,
Mike
Hi Mike,
Thanks for your answer.
In fact, we’re going to propose to our client to apply only RU’s, every six months.
But, it would be useful if I knew clearly the difference between functional and regression fixes.
I think regression fixes fix functionality which used to work in a previous RU or RUR but is broken in a later release RU or RUR
Functional fixes fix code is not working as expected. This code is mostly introduced in the previous release
Regards,
Jorge
Jorge,
I tried to find an official definition – but wasn’t successful.
You may try to clarify the terms via an SR please.
Thanks,
Mike
Clear explanation. Thank you.
Hi Mike,
What’s still unclear to me is when are individual fixes included in a RU? How is it decided which fixes are included in the next RU, what’s the process behind this?
We still have to request new patches for the same year old bugs every quarter when we install the latest RU. I would expect them to be included in one of the future RUs in a timely manner.
Thanks,
Thomas
Hi Thomas,
this is an excellent question – and if I’d be the product manager for patching, I’d explain this as a blog post 🙂
Yes, it is true. You have to request one-off fixes over and over again on top of an RU unless they are included in an RU.
Unfortunately. This is tiring and time-costly as it prevents you from using the RU as quickly as possible. But on the other side, our patching group can’t include every fix as RUs otherwise would be massive.
How do “they” consider a patch to be included?
There are a lot of parameters adding to a score. One decision factor for instance is, if it was a highly critical fix. Or if something hit a lot of people. There is a number of other factors. And all those add up and bring a patch on the list for inclusion.
Hope this helps to understand – and I know, it doesn’t make it more satisfying to you 🙁
Cheers,
Mike
Hello Mike,
So, now there are at least four versions 12.2., 18.3, 18.4 and 19.4 with different features?
Hi Gerrit,
what do you mean with “there are at least four versions [..] with different features”?
Cheers,
Mike
Hi Mike,
Many thanks for great article, that is very helpful and contains best information ı have ever seen about PSU,BP,RU;RUR differences on internet..
But I want to kindly ask some question
According to this article actually psu and rur totally same or maybe I missed someting
Two of them has only security + regression fixes so why rur is different from psu
I have already read other post about PSU;RU;BP;RUR. Most of them I noted that..
RUR is more or less same PSU –> RUR dont replace PSU, RUR is not same PSU, RUR is different from PSU
RU is more or less same BP —> RU replaces BP
RU or RUR difference is clear
PSU and BP difference is clear
RU and BP relation and replacement is clear
but RUR and PSU replacement is not clear for me
Hi Baris,
thanks 🙂
And no, PSUs and RURs are not the same.
First of all, you shouldn’t consider RURs at all ( https://mikedietrichde.com/2018/11/08/why-release-update-revisions-rur-are-tricky/ ).
Second, there is no such thing as PSUs anymore. PSUs were very limited in content and lead to a huge amount of one-offs and merge patches.
RURs are based on RUs.
And the only analogy to previous namings is:
BPs and RUs are the same from content.
Cheers,
Mike
Hi Mike,
As I already send before a few minutes ago I got my miss and please forget about it 🙂
RUR and PSU is not same and different because
Althought both of them have security and regression fixes and cimulatively , RUR is containing optimizer + functional fixes from initial base RU-1 for every cycle.
Many thanks for helpful article.
Barıs.
Thanks Mike,
Can you do a simple version of this for 19c only as that’s the main release.
Thanks, Duncan
Hi Duncan,
not sure what you are requesting? The same principle applies to 19c.
Can you please let me know what you are missing?
Cheers,
Mike
Hi Mike,
thanks for the details, still a little but confuse. Hope you can help me here.
If have installed Database Release Update 19.12.0.0.210720 Patch 32904851 and OJVM Release Update 19.12.0.0.210720 Patch 32876380. Is it possible install JDK8u301Patch 32918394 (Bundle Patch) or is not required at all since I already have 32876380 OJVM?
Thanks in advance,
Tom
Hi Tom,
you may need the newest JDK in addition as well. See:
https://mikedietrichde.com/2020/04/22/jdk-patching-happens-with-every-ru-since-january-2020/
Cheers,
Mike
Mike
With the January 2022 Security Alert I am seeing the options of “Database release update.” and “GI release update” does “Database release update” corresponds to CPU and “GI release update” to PSU or does “Database release update” corresponds to CPU/PSU and “GI release update” corresponds to RUR?
Based on the size of the file I am thinking the Database release is the CPU and the GI release is the RUR.
Thanks in advance for any clarification you can provide.
Hi Philip,
no – there are no PSUs anymore.
A release update is the same as a bundle patch before 12.2.0.1. Same contents.
While the RUR add security and regression fixes the next quarter and the quarter after.
Please watch Episode 1 here where we explain the entire topic in detail:
https://mikedietrichde.com/videos/
Cheers,
Mike