I’ve had this topic on my “to write about” list for a long time. But somehow it felt through the cracks. Especially in relation to the recently announced extension of the Oracle Database 19c Premier and Extended Support periods it may be useful if you are aware of this policy since you may ask yourself: How long can I request a backport for Oracle Database RUs?
Photo by Pawel Janiak on Unsplash
What is a backport?
As we explain in Virtual Classroom Seminar – Episode 17: From SR to Patch – Insights into the Oracle Database Development process we fix issues in the MAIN code line at first, even though you may have hit a new problem in let’s say 19.24.0.
Bug fixes will be done in the MAIN code line at first
Once the fix has been created in the MAIN code line, you can request a backport on top of your current patch release.
Backport fix gets produced on top of your current Release Update, in the example on top of 19.24.0
This is also why we ask for the output of opatch lsinventory and opatch lspatches. We need to understand exactly which patches you applied to avoid any conflicts with your existing fixes with the one we produce now. In addition, we potentially need to merge the backport into other fixes you may have in your environment.
So you see, this is a fairly complex process.
And in a later stage, this fix may be a candidate for inclusion into a future Release Update. If you want to know more about the selection criteria, please watch From SR to Patch – Insights into the Oracle Database Development process.
Where are the rules documented?
You can find the policy via MOS Note: 209768.1 – Oracle Database, Fusion Middleware, Enterprise Manager, and TimesTen In-Memory Database Software Error Correction Support Policy. It links to a PDF named Oracle Database Error Correction Policy (Oracle Database 19c and Higher). On page 7/8 you will find the following explained:
Oracle recommends implementing a process to maintain up-to-date environments. The following policy applies:
1. Quarterly proactive patches(1) (RU/BP) released during the first 3 years of a Database Release’s GA date(2) will be eligible for new interim fixes for 12 months from that RU/BP’s release date
2. Quarterly proactive patches(1) (RU/BP) released more than 3 years after a Database Release’s GA date (2) will be eligible for new interim fixes for 24 months from that RU/BP’s release date
3. Customers running an older quarterly proactive patch(1) (RU/BP) that falls outside the documented windows (1,2) above will be eligible to download existing interim fixes only, i.e. new fixes will not be provided.
An example follows on the next page in the PDF.
The ratio behind this is clear and obvious. You should patch on a regular basis, and not count on this single one-off interim fix for a specific issue. Release Updates contain a significant number of fixes, and many of them – especially the security fixes – will be very important for your environment.
How long can I request a backport for Oracle Database RUs?
This is the question you may ask yourself at this point. Will you still get a fix on top of 19.8.0 in year 2024?
Clear answer: No, you won’t.
But since the above policy may not be obvious to everybody when you don’t deal daily with it, let me explain this with some examples.
At this point, the purpose of this blog post may be more clear to you. I’d like to explain the policy behind the backport process to allow you a better planning, especially now under consideration of the significantly extended support time frames for Oracle Database 19c.
12 months backport time frame apply during the first 3 years after general availability of the release, then from there 24 months
This means that in the first 3 years after the GA date (general availability) you will get backports on top of a 1 year old Release Update, but not for a release update being 1.5 years available already. After 3 years into 19c lifetime, you can now request backports on top of an RU being maximum 2 years old.
I think three examples make this even more clear.
Example 1 – You are on 19.14.0 today
The Release Update 19.14.0 has been released within the first 3 years after GA. You had 12 months backport support for it.
Example 1: You are still using 19.14.0 end of year 2024
This means, you could request backports on top of 19.14.0 for a period of 1 year, i.e. until January 2023. Since this is almost 2 years back, you won’t receive any backports for 19.14.0 anymore.
Example 2 – You are on 19.16.0 today
You thought you were progressive by using 19.16.0 at the end of 2024, right?. In the below graphic you see that 19.16.0 has been released more than 3 years after GA. Hence, 24 months backportability apply to it.
Example 2: Even for 19.16.0 release 3 years after GA you won’t receive any backports anymore today
Bad news for you. Even though 19.16.0 had two years of backportability, the period ended in July 2024. Now, since we are at the end of calendar year 2024, you won’t receive any new backports on top of 19.16.0 either anymore. You need to move on.
Example 3 – You are on 19.22.0 today
Well, my Support heart makes me tell you that 19.22.0 is almost 1 year old. You should patch more often. But I see that some of you have constraints, requirements or something I have no insights into. But I have good news for you. 19.22.0 got release more than 3 years after GA, and it isn’t 2 years old yet.
Example 3: You are on 19.22.0 end of 2024, and you can request backports on top until January 2026
You can request backports on top of 19.22.0 until January 2026, from now on for more than 1 year. This seems to be quite comfortable even though I would highly recommend that you move forward to a newer Release Update.
I hope this clarifies the policy linked from MOS Note: 209768.1 for you.
Further Links and Information
- Virtual Classroom Seminar 17:
From SR to Patch – Insights into the Oracle Database Development process - Important Update to the Oracle Database 19c Support Timeline
- MOS Note: 209768.1 – Oracle Database, Fusion Middleware, Enterprise Manager, and TimesTen In-Memory Database Software Error Correction Support Policy
