Important clarifications to the Oracle Database Error Correction Policy

When I came back from vacation a few weeks ago (or was it almost 2 months ago??) I learned that we have added some Important clarifications to the Oracle Database Error Correction Policy. The clarifications are mainly about how long you will be able to request a single fix for a given Release Update (RU). Take this not as a constraint but a motivation to argue internally to not stay on too old Release Updates.

Photo by Saul Macias on Unsplash

How to find the important notes?

It is not easy to find this important note in MOS, especially since it contains a PDF containing the policy. A customer (Thanks, Gagan!!) has sent it to me before.

Start your MOS journey here:

• MOS Note: 1351163.1 – Lifetime Support and Support Policies – Oracle Database Overview

In this note you will find the three important links for the Support and patching policies:

• Lifetime Support Policy
• Technical Support Policy
• Database Error Correction Policy

and important exceptions, too.

In my particular case, I was looking for the Database Error Correction Policy which is linked as MOS Note: 209768.1 – Database, FMW, Enterprise Manager, TimesTen In-Memory Database, and OCS Software Error Correction Support Policy which then has a link to download the policy as a PDF.

Since the customer who sent this to me pointed out some important changes on Aug 2, 2023, the rules and the wording have been clarified, and examples have been added. The current version of the policy is from Oct 4, 2023. And once you read this blog post, maybe weeks or months after I wrote it, you may need to checkout the current revision of it by yourself.

What are the clarifications and changes?

You will find the important clarifications on page 7 in the paragraph 3.1 Release Update.

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.

4. Monthly Recommended Patches (MRPs) will be supported on the two most recent RUs only (Linux x86-64)

The two footnotes get clarified as:

(1) Quarterly Proactive Patch (RU and BP) release dates for each platform are found in MOS note 888.1

(2) The Lifetime Support Policy starts the GA timer with the release of a Database on Linux x86-64, on-premises. The GA date for Database Releases can be found in MOS Note 742060.1.

Examples

When you look at the examples provided in the document, it will become clear immediately:

Example 1: RUs released in the first 3 years of GA date have a 12 month fix window
o   19.4 RU, released in July 2019, would be eligible for bug fixes through July 2020
o   19.14 RU, released in January 2022, would be eligible for bug fixes through January 2023

Example 2: RUs released more than 3 years after GA date have a 24 month fix window
o   19.15 RU, released in April 2022, would be eligible for bug fixes through April 2024
o   19.20 RU, released in July 2023, would be eligible for bug fixes through July 2025

What does this mean for you?

In consequence, you hopefully see this is a useful clarification and rule. At least not for those of you who have been patched to RUs newer than 19.14.0 already. And please don’t misinterpret this clarification. It gives you a firm confirmation about how long you can request one-offs on top of a given Release Update.

And of course, there is another important aspect, too. We don’t want you to stay on outdated and very old RUs forever. For us it is very hard to provide new one-offs on very old patch bundles.

I personally can tell you from my years in Oracle Support that one of the worst cases is always when you as a customer hit an issue we fixed for a long time already in a newer patch bundle. Take 19.20.0 for instance, it contains more than 3891 fixes on top of 19.13.0. As our teams deals a lot with customers with real-world complex migrations, missing so many fixes always leads to trouble and frustration. Hence, it makes a lot of sense to me to limit the time to request new one-offs on old RUs but in addition give a comfortable 24 month period for newer RUs.

If you don’t believe it, checkout also my previous blog post about How Many Fixes Are You Missing, and especially how many of them are security fixes. and query it by yourself with ORAdiff.

Further Links and Information

• MOS Note: 1351163.1 – Lifetime Support and Support Policies – Oracle Database Overview
• MOS Note: 209768.1 – Database, FMW, Enterprise Manager, TimesTen In-Memory Database, and OCS Software Error Correction Support Policy
• Download the Oracle 19c and above Database Error Correction Policy as PDF
• How many fixes are you missing?

–Mike