Oracle is about to publish a new release for Database and Grid Infrastrcuture. As it has been anounced time ago, there will be important changes related to new version and patches policies for these products.

Firstly, what should be named version 12.2.0.2, will finally be Oracle 18 (18.1.0). This is not just a name changing, Oracle will publish yearly a new major release for the database (next one will be Oracle 19 and it’s supposed to be last 12c technology product for database).

New functionalities for a release will no longer be published as Patch Sets. PSs are substituted by Release Updates (RUs). Also, Patch Set Updates are substituted by Release Update Revisions (RURs). Both will be published in a quarterly manner.

New database and GI versions will so bring a new naming convention using three fields: year, update and revision. Each quarter new RUs and RURs will be available and new functionality (RU, giving versions 18.1, 18.2, 18.3 and so on) or new security and issue patches (RURs – 18.2.1, 18.2.2 and 18.2.3, no more thah 2 RURs per RU) will be ready for going live.

Targets for these changes

What do Oracle says are the principal targets for this change?

• Lower times for new functionalities to arrive into production.
• Best software quality with the reduction of the changes in each evolution (Agile / DevOps? 🙂 )
• Attempt to avoid the need of applying one-off patches. This is just good news for us, Arumel, as we like to use structured policies for deploying full pack of patches (i.e. PSUs) reducing the complexitiy for future upgrades / patching operations.
• Maintain the posibility of security and bug corrections patching with no evolving (new functionality / optimizer changes) changes. This is similar to current PSUs.

Version roadmap

We can see in a simpler manner the lifecycle and schedule for new releases. Complete information is available at MOS note Release Update Introduction and FAQ (Doc ID 2285040.1).

Version 18.1.0 will see its first RU in Q2. In Q3 the quarterly new RU will also be available, and the first RUR will be available for 18.2 (18.2.1). In Q4 RU 18.4.0 should be published and also 18.2.2 RUR, last revision for 18.2. After this RUR, it will be necessary to evolve to a new RU if we want new patches available for our database, thought Oracle indicates support will be still available even when software is out of current RU / RUR.

It’s interesting to know that RU and RURs published in the same quarter will be at the same patch level. Inside same release, RU and RUR levels with similar sum will indicat same patch level, so same vulnerabilities and bugs are expected to be solved in them.

First impressions

After checking new evolve / corrective policies, I end with some impressions:

• Fewer changes simpler to apply vs smaller lifecycle for a RU (only 6 months with guaranteed updates). Up to two Revisions for a RU.
• This shorter lifecycle does not imply to be out of support if we are not working with a current RU / RUR combination. Oracle will maintain the support even for opening new patch requests as indicated in MOS note. This can avoid extra stress for correctly maintaining all of our software under support.
• RUR will not include new functionalities (similar to PSUs).
• RUs and RURs are independent and they both are full versions, so it won’t be necessary to apply a previous RU if we want to upgrade to a specific RUR. Going from 18.2.1 to 18.3.2 should be possible installing only one new software version.
• There’s a cummulative criteria for going into different RU / RURs versions. Basically, the patch must be always newer, so moving from 18.2.2 to 18.3.0 will not be supported.
• OJVM upgrade will still be a nightmare for DBAs. Oracle says it is working to improve this patching, but at the moment there’s no guarantee of integration of OJVM patching inside RU / RURs.
• Windows version will continue with Bundle Patches and this changes do not apply in this platform.
• 12.2.0.1 and 11.2.0.4 will still be using PSUs, RU and RUR will start from Oracle 18 (12.2.0.2).
• Oracle 18 and 19 are expected to be the versions that will complete the 12c support lifecycle.
• As versións 18 e 19 cubrirán o ciclo de vida previsto para a versión 12c.