Oracle 18c RU and RUR for pioneers and followers

By Franck Pachot

.
In a previous post, I explained the announcement of the new release model, with Release Updates and Release Update Revisions replacing Proactive Bundle Patch and PSUs. Here is a description that will help you to plan your patching activity.

Which DBA are you?

There are currently a lot of discussions about the different types of DBAs. When it comes to patching, the DBA type is important.

Some DBAs are very conservative: do not use new features, do not upgrade to ‘.1’ releases, because every change can break anything. At least, maybe just patch to SPU for the security fixes. Some are more confident and apply the PSUs, with more fixes. The problem is that what is not fixed may be subject to a bug one day, and need an urgent one-of patch.

And some others are very pro-active: they patch and upgrade the development environment as soon as there is a new Proactive Bundle Patch, then they always have the latest fixes.

Actually, this does not depend only on the personality of the DBA but also on the ability to test. If you have only the production database with representative volume and activity, then any patch set can be dangerous. If in addition to that any intervention or decision takes 3 months, the problems encountered are even worse. But if you are in DevOps, where developers work on a production copy, when integration tests run every night, covering most of the critical use cases, then you can be confident that once those databases have run a few days with the latest Proactive Bundle Patch, then you can do the same in production. And if you come upon the low probability of a regression, you can react immediately with workarounds because you are agile.

The SPUer, the PSUer and the PBPer

In the previous release model, still used for 11g and 12c up to 12.2, this context will define if you are a SPUer (only security patches with very low risk of regression), PSUer (the critical fixes), or Proactive BPer (more fixes) but this will still not include optimizer fixes, and then may still require one-offs.

The .0, the .1 and the .2

With the new release model, you will have releases (R) every year, like 18c, increasing the first number, such as 18.1.0 which should arrive in January. Then during the support window, you will have Release Updates (RU) release quarterly to proactively bring software to the lasted fixes, increasing the second number, such as 18.2.0. But, because those may bring some regressions, you will have additional Release Update Revisions (RUR) which will fix the issues encountered in the last 6 months Release Updates, increasing the third number, such as 18.2.1 and 18.2.2

Then, there will be 3 types of approaches

The pioneer will go to the latest software

The pioneer is confident in his ability to cover most of the critical uses cases in his automated regression tests and is agile enough to fix quickly any issue in the non-covered cases. Then, he will upgrade to release 18.1.0 in January 2018. He will apply the Release Updates as soon as they are there: 18.2.0 in April, 18.3.0 in July, 18.4.0 in October. In January 2019 he can apply the 18c release update 18.5.0 or upgrade to 19c release 19.1.0

The wise will be on the latest Release Updates (RU)

Because each release brings a bunch of new features, they may come with regression on existing ones. Then, the wise DBA will prefer to wait that the pioneers have encountered them and that Oracle has fixed them in Release Updates. He can upgrade to 18.2.0 in April 2018, then apply the RU as they are released: 18.3.0 in July, 18.4.0 in October, 18.5.0 in January 2019,… He can continue for few years according to the support lifecycle (MOS 742060.1)

Of course, he doesn’t need to apply the RU immediately and can choose to lag for a few ones in order to be sure that more pioneers or eager wise ones have encountered more issues. But then, he will also lag on the security fixes, which is not good. And this is where Release Update Revisions come up.

The follower will be on the latest revision (RUR)

When you want to be up-to-date only on security fixes, with the minimal risk of regression, you will stay on the RUR branch, where the potential issues encountered on RU will be fixed. This is the same philosophy as applying only the SPU in the previous release model, but without lagging for years on other fixes. In the new release model, the RUR will be provided only for the last two previous RU. This extends the lifetime of RU by 6 months. The follower can apply the latest security fixes, but they will also come with other fixes. However, the risk is lowered here because the other fixes included are only those that have been tested for 6 months by other users. This 6 month lag on pro-active fixes keeps the risk minimal without running old software. He will upgrade to 18.2.1 in July for a 3 months lag, or waits October to upgrade to 18.3.2 for a 6 months lag.

Update Oct-2017: To make it clear, the follower will not have to install a RU before a RUR. In the example above, after 18.3.2 the follower, who wants to continue to apply security fixes only, will have to apply the 18.4.2 RUR which includes the 18.4 RU patches. But this will be 2 quarters after the 18.4 RU release, and then the regressions encountered during 6 months have been fixed.

So what?

Of course, you don’t have upgrade to 18c immediately and to patch every 3 months. But when you want to patch, you have the choice to be on the latest software to get new features immediately, or on latest RU to get new fixes immediately, or on latest RUR to let the others endure early problems for a few months. Be aware that RUs have a bit more than what Proactive BP included. In RU you may have some optimizer fixes, but those are disabled by default if there is a risk of plan change. You may also find some minor enhancements. You have the flexibility to switch between RU and RUR when you want, depending if you want some latest fixes or not. And in the low probability that you need a one-off patch, it will be delivered quickly for the latest RU and RUR.

Note that each release will be supported 3 years which means that you have the choice to go to the next one when you want the features that come with it. In 3 years, you will have the choice to run version 18.12 or 19.5 or 20.1 and with additional RU or RUR.

Just a guess: if Oracle continues with’Cloud First’ release, there are good chances that we will get 18c on-premises starting with 18.2 after a few months running 18.1 on the Cloud.

This new model helps to run a software that is not too old, which is more and more mandatory, at least for security reasons. Finally, all is about testing. Do you prefer to let others test the quarterly upgrades on their database, in the hope that what they run is similar to what you run on your database? Then be a ‘.1’ or ‘.2’ RUR follower. Or improve and automate your own testing and you can reduce the lag by being an up-to-date ‘.0’ RU patcher.

Update Nov-2017

Please remember that this blog post has been written before any RU and RUR were released. This ‘follower’ way to go may not be possible if Oracle realizes that the RUs are stable enough and do not need to release quarterly RURs. And anyway, at each quarter, you have the choice between latest RU or RUR.