Oracle Patching RU & RURs

 

Oracle Patching RU & RURs:-

What is an RU?

An RU is a Release Update. And there’s not much difference except for the name to an Proactive Bundle Patch.

In addition, there are RURs: Release Update Revisions.

Those are very similar to Patch Set Updates containing less changes.

 

Note: No RUs and RURs for Oracle Database 12.1.0.2 and Oracle Database 11.2.0.4 but still – as before – SPUs, PSUs and BPs

 

Key highlights here are 

1. Yearly new major release
2. Quarterly new release update
3. Quarterly new release update revision

 

Oracle’s new release model includes

·       Yearly new releases (and numbered according to the year) instead of a multi-year cycle. Most annual releases will be supported for three years and outlined in the Lifetime support policy document.

·       Quarterly Release Updates (RUs are already introduced and part of 12.2) 

·       Quarterly Release Updates Revisions (RURs are already introduced and part of 12.2)

 

·       The installation method of RU/RUR is to still use the existing Opatch technology to install.

·       The naming rules of RU/RUR are as follows:

Release Update (RU) - Database Release Update 12.2.0.1.<build-date>

Release Update Revision (RUR) - Database <Quarter> Release Update Revision 12.2.0.1.<build-date>

 

<Quarter> is 'MMM YYYY'

<build-date> is YYMMDD

 

 

The format for the release model is <year>.<update>.<revision>

·       <year> is the delivery year for the release and will start with 18c=12.2.0.2 and 19c=12.2.0.3

·       <update> stands for the RU level

·       <revision> stands for the associated RUR level

The first digit is the major version number of the Oracle database, such as Oracle 19c, 18c, 12c. 

Starting from Oracle 18c, the first number indicates the initial year of the release of the Oracle database version.

For example, 2018 is the initial year of release of Oracle 18c (18.0.0.0.0).

The second digit is the release quarter of Oracle RU (Release Update). 

For example, 19.3.

The third digit is the release quarter of Oracle RUR (release updates revision), such as 19.2.1, 19.2.2.

 

Version	Release	RU	RUR
18.1.0	18	1	0
18.2.0	18	2	0	First Release Update
18.2.1	18	2	1	First Release Update Revision for RUs from the last six months

1. RU is proactive and highly tested, bundled with many important fixes, which can enable customers to avoid many known problems.

2. RUR includes security and fallback repairs to RU, extending the life cycle of RU by two quarters. Each RUR is only for a specific RU.

 

 

Shipping date	RU	RUR
	January, April, July, October	January, April, July, October extend the RU’s lifetime up to two quarters
Deployment	Specific to a particular annual release. RUs are full patches	Specific to a particular RU. RURs are supersets of all RUs where the second field is smaller than or equal to the RURs second field.  You are not required to first apply a prior RU.

Oracle’s Release Updates (RU) and Release Update Revisions (RUR) timeline:

	Jan-18	Apr-18	Jul-18	Oct-18	Jan-19	Apr-19	Jul-19	Oct-19
RU	18.1.0	18.2.0	18.3.0	18.4.0	18.5.0	18.6.0	18.7.0	18.8.0
RUR #1			18.2.1	18.3.1	18.4.1	18.5.1	18.6.1	18.7.1
RUR #2				18.2.2	18.3.2	18.4.2	18.5.2	18.6.2
RU					19.1.0	19.2.0	19.3.0	19.4.0
RUR #1							19.2.1	19.3.1
RUR #2								19.2.2

 

18.1.0 and 19.1.0 are planned without RURs.

A release Update or Revision is only a patch, not a database upgrade.

Few important things:

§  There will be no more than two RURs for each RU (e.g. 18.2 will have only 18.2.1 and 18.2.2)

§  If applying a RUR, after 6 months at latest, the DBs must be patched to a greater level of RU.

§  Applying the second RUR of each RU (e.g. 18.2.2 -> 18.3.2 -> 18.4.2) is the most conservative approach whilst keeping up to date with the latest critical fixes.

 

Let's understand by example

1. Oracle released 18.1.0 release in 2018 Production (yearly release)

2. In April they released 18.2.0 

This is a release update.  It contains all the regressions,  security fixes, optimizer and functional fixes

3. Similarly in July they will release 18.3.0

This is again a Release update

A release update is quarterly 

4. In July they will also release 18.2.1 - a patch or a release update revision (RUR)

 A RUR is like a patch and is installed on top of existing Release Update, however it does not contains any Optimizer or Functional Fixes, they are only present in Release Update. 

5. Now in October they will release

§  RU - 18.4.0 

§  RUR - 18.3.1

§  RUR - 18.2.2

6. finally Every year a new release 19 in 2019, 20 in 2020. 

The licensing aspect is to be decided by Oracle, that is which all releases are going to part of same license set.

Here is what I mean in a photo. 

If you notice the # of lines corresponding to each feature (functional, optimizer etc), you will notice they are only added as part of Release updates and not part of Release updates revisions on the release. 

However if you do a sum  for example 

18.4.0 and 18.3.1 (sum of second 2 decimal places), the fixes for regressions and security are same (but not optimizer and functional)

Upgrades (Release and RU) and patches (RUR) ?

A complete timeline example of Oracle releases and upgrades is below - 

You can upgrade in the same column from bottom to top (i.e keep adding features, you cannot remove any)

Upgrade (or patch) from left to right. All the green arrows are supported and the red ones are not. 

New quarterly Release Update (RUs)
– More aggressive patching for test / dev and early production roll-outs -> more testing required
– Released quarterly (Jan, Apr, Jul, Oct)
– Proactive, highly tested bundles of critical fixes
– Include all security fixes for the same quarterly cycle
– Enable customers to avoid known issues.
– Might contain small, important new features
– Query optimizer fixes that can change execution plans might be included but must be enabled manually by the customer after patching.
– Separate Database RU, Grid Infrastructure RU, and OJVM RU available

 

New quarterly Release Update Revisions (RURs)
– A bit similar to former PSUs
– Less aggressive pathing for stable production environments -> less testing required
– Released quarterly (Jan, Apr, Jul, Oct)
– Contain security and regression fixes
– Include all security fixes for the same quarterly cycle
– Applied to a particular RU
– Extend lifetime of RUs up to 2 quarters
– No new features included
– No RURs for Windows available

You can switch back and forth between RUs and RURs

Interim patches will be delivered on top of base version and on any RUs or RURs for a supported release as long as technically feasible

 

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.

Stay with Updates (RU) instead.

Makes your life much easier.

Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)

Applying RU (Release Update) to Oracle 18c:--------->

The following is the guide in how to apply RU to Oracle 18c release, as you might know Oracle introduced 18c on-premise with 18.3 release.

Here I am applying January 2019 Oracle Security Patch release which is 18.5.

Download the latest RU patch and place it in a directory accessible by your database server:

$] cd /oracle-app/linux/18c_RU/18.5_DB/28822489

$] $ORACLE_HOME/OPatch/opatch apply

$] sqlplus / as sysdba

SQL> STARTUP

exit

$] cd $ORACLE_HOME/OPatch

$] ./datapatch -verbose

Post-Patch verification:

sqlplus / as sysdba
SQL> @?/rdbms/admin/utlrp.sql

//check your database components

SQL> select COMP_NAME,STATUS from dba_registry;

// query to list applied patches on the database instance:

SQL > select * from dba_registry_sqlpatch;

 So the database has been successfully patched with full release number 18.5.0.0190115