Oracle Database 18c
Oracle Database 18c
By Mike Appleyard
On 17 May 2018

Around the end of September 2017, Oracle announced a few details of its latest version of the world’s Number #1 database software, Oracle RDBMS - along with a new naming convention. Most of you will be familiar with - and will be running - Oracle Database versions 11gR2 and 12cR1, and a few of you will be running 12cR2 – which itself was only released in March 2017.

Oracle has decided to follow the naming convention of a few other major software suppliers and have a release schedule and a naming convention aligned to the calendar, hence Oracle Database 18c being released in March 2018; albeit only for the Oracle Cloud so far and not On-Premise. On- Premise versions are scheduled for the second half of 2018. Additionally, at first sight, it also looks like Oracle intends to have a major release every calendar year. Here’s the current Oracle Road map from My Oracle Support Note: 742060.1 which you can read in full here.

oracle release

In days gone by, we’ve all got used to Oracle releasing major functionality and new features with the announcement of a new release version, for example 10g (10gR1), 11g (11gR1), 12c (12cR1), and then another release of major functionality in what was known as a ‘dot’ release - for example 10gR2, 11gR2, 12cR2. So, whilst you had an idea that there were major changes in the release, Oracle had such a sporadic and variable gap between releases that you never really new when the next major release was going to be. There was nearly a four-year gap between 11gR2 and 12cR1 and over four years between 12cR1 and 12cR2!

You can also see that at the same time, Oracle has changed what it now considers to be a major release. The roadmap above shows that what would normally be a Patch Set Release – – the first Patch Set for Oracle Database 12cR2, is now a major release – 18c. Additionally, the next release after that which would also normally be a Patch Set Release –, is now also a major release – 19c.

But Mike, this is just a numbering system and a naming convention. It doesn’t really affect us or change anything does it?

Well yes, potentially, it does.

I’ve been working with Oracle for over twenty years now, and such a large percentage of customers, even today, would never consider upgrading to the first release of a new version. How many of you never ran 10gR1? Or 11gR1? Or 12cR1? Not many I would wager! Many customers for some reason would always avoid the ‘first’ release, 11gR1 for example, considering it too ‘new’, perhaps ‘flaky’ and ‘buggy’ - so would wait for the ‘second’ release thinking it would be more ‘stable’ and less ‘buggy’. So, I bet you’ve probably all run 10gR2 and 11gR2 on many Production systems.

A lot of customers also don’t upgrade to each Patch Set Release. For example:, and, not because of the concerns above, but mainly because Oracle released them every 12 months or so, and there are simply too many Oracle databases to upgrade and you would constantly be applying Patch Sets every day of your working life!

Therefore, it seems that Patch Sets are to be a thing of the past, and a major version release every calendar year is to be the norm.

You might still be wondering how this affects you, if you never used the ‘first’ release and didn’t apply every Patch Set?

At this point in time, we don’t actually know for sure, but our concern is how it affects the amount of time that a major release is supported. For 12cR2 ( and the next two releases, 18c and 19c, replacing Patch Sets and respectively, Oracle has stated that currently, the support rules do not change. However, beyond that, we do not know; but from the diagram that follows below, it indicates that customers will be in a better position to:

  • Predict the release schedule of the Oracle Database
  • See the support lifetime of a release
  • Plan a regular patching policy that fits in with governance and compliance
  • Plan and test upgrades in advance
  • Reduce risk to the business of exposure to bugs and security issues

What we do know, is that Oracle’s schedule for major, minor and patch releases are as follows:

oracle schedule

And that it all gets a little more complicated in terms of what can be upgraded to what!

We now have the arbitrary Release – 18c, 19c – expected to be annually.

We have the Release Update (RU) – 18.1.0, 18.2.0, 19.1.0, 19.2.0 – expected to be quarterly.

And the Release Update Revision (RUR) – 18.2.1, 19.2.2 – also expected to be quarterly.

Oracle states that there will be no new functionality in a Release Update Revision (RUR) (thank you Oracle!), and that RURs will be full patches, so can be installed into a brand new Oracle Home - which has definitely made life a little easier since they brought that in with Patch Sets a few years back.

But new functionality will highly likely be included in Release Updates like 18.2.0 ad 18.3.0. By the way, did you know that Oracle had been putting major new features and functionality in Patch Sets for while now? Oracle Database In Memory Option, JSON in along with major new functionality in the release of Oracle Multitenant?

Oracle have stated that each Release Update (RU) – 18.2.0, 18.3.0, will have two Release Update Revisions (RURs) quarterly -18.2.1, 18.2.2 & 18.3.1, 18.3.2. Note that 18.1.0, 19.1.0 will not have any Release Update Revisions!

Confused? Wait until you’ve upgraded to 18c or later and now need to patch or upgrade to a later Release Update, or a Release Update Revision…

Can you simply upgrade to the ‘latest’ Release Update or Release Update Revision? It would appear you have to be good at maths in order to work this out.

Oracle states: “Customers can move from Updates to Revisions and back again as long as they choose versions that are cumulative of one another. A simple formula to determine cumulativeness within the same feature release is to add the second and third fields of the version for the source and destination update. If the sum of these fields for the destination update is greater than or equal to the sum for the source, it is OK to move. If not, a patch application error is issued.”

And the examples are:

Example 1:

source - 18.2.2 - sum of second and third fields is "4"
destination - 18.5.0 - sum of second and third fields is "5"
conclusion: destination "5" is greater than or equal to source & "4"; so it is OK to move

Example 2:

source - 18.2.2 - sum of second and third fields is "4"
destination - 18.3.0 - sum of second and third fields is "3"
conclusion: destination "3" is less than source "4" so a patch application error is issued

That’s a bit weird – you could be forgiven for quite naturally thinking 18.3.0 is an upgrade from 18.2.2! At least when 19.1.0 comes out, Oracle is saying you can upgrade directly to that from an 18.x.x release!

For full details of what you can and cannot do, please read My Oracle Support Note: 2285040.1 which can be found here.

Trying to read between the lines, if you patch regularly, and hence are likely to be much more affected by this than those who don’t, then:

  • Release Updates (RU) patches right now are more or less the same as Proactive Bundle Patches (BPs)
  • Release Update Revisions (RUR) patches right now are more or less the same as Patch Set Updates (PSUs)
  • The plan is to release only two RURs per RU
  • Quarterly schedules stay as before
  • Interim (one-off) patches still exist I hope that helps explain some of the confusion around this. Look out for my next blog covering a few details of what’s actually new in Oracle Database 18c!

If you have any questions, and would like to speak to someone regarding your Oracle Database, please contact

Get in touch

We always put our customers first. Contact us by using the form below, and we will get back to you as soon as we can.