Oracle Home Management – part 4: Challenges and Opportunities of the New Release Model
Starting with the upcoming next release (18c), the Oracle Database will be a yearly release. (18c, 19c, etc). New yearly releases will contain only new features ready to go, and eventually some new features for performance improvements (plus bug fixes and security fixes from the previous version.)
Quarterly, instead of Patch Set Updates (PSU) and Bundle Patches (BP), there will be the new Release Updates (RU). They will contain critical fixes, optimizer changes, minor functional enhancements, bug fixes, security fixes. The new Release Updates will be equivalent to what we have now with Bundle Patches.
The Release Updates will be released during the whole lifetime of the feature release, according to the roadmap (2 years or 5 years depending on whether the release is in Long Term Support (LTS) or not). There will be a Long Term Support release every few years. The first two will probably be Oracle 19c and Oracle 23c (I am deliberately supposing that the c will still be relevant ).
Beside Release Updates, there will be the new Release Update Revisions (RUR), that according to what I have read until now, will be released “at least” quarterly. Release Update Revisions will contain only regression fixes for bugs introduced by RUs and new security fixes, very close to what we have now with Patch Set Updates.
Release Update Revisions will cover ONLY 6 months, after that it will be necessary to upgrade to a newer Release Update or to a newer major release. Oracle introduced this change to reduce the complexity of their release management.
This leads to a 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.
On top of that, one-off patches will still exist. For more information, please read the note Release Update Introduction and FAQ (Doc ID 2285040.1)
It is clear that it will be complex to keep the same major upgrade frequency as today (I expect it to increase). There have been from 3 to 5 years between each major release so far, and switching to a yearly release is a big change.
But the numbering will be easier: 18.3.2 is much more readable/maintainable than 18.104.22.168.BP180719 and, despite it does not contain an explicit date, it keeps it easy to understand the “distance” with the latest release.
So we will have, on one side, the need to upgrade more frequently. But on the other side, the upgrades might be easier than how they are now. One thing is sure, however: we will deal with many more Oracle Homes with different patch levels.
The new release model will bring us a unique opportunity to reinvent our procedures and scripts for Oracle Home management, to achieve a standardized and automated way to solve common problems like:
- Multiple Oracle Homes coexistence (environment, naming conventions)
- Automated binaries setup (via golden images or other automatic provisioning)
- Database patches
- Database upgrades
In the next post, I will show my idea of how Oracle Homes could be managed (with either the current or the new release model), making their coexistence easier for the DBAs.
Bonus: calculating the distance between releases
For a given release YY.x.z, the distance from its first release is ( x + z -1 ) quarters.
E.g.18.3.2 will be ( 3 + 2 – 1 ) = 4 quarters after the initial release date.
Across versions, assuming that each yearly release will be released in the same quarter, the distance between versions YY1.x1.z1 and YY2.x2.z2 is:
( YY2 – YY1 ) * 4 + ( x2 + z2 ) – ( x1 + z1 ) quarters
E.g. : between 18.4.1 and 20.1.2 the distance will be:
( 20 – 18 ) * 4 + ( 1 + 2 ) – ( 4 + 1 ) = 6 quarters