You MUST patch 12.1.0.1 and 11.2.0.3 and older databases before June 2019

First of all, this blog post is not new. I blogged about this SCN topic a while ago already. But some of you seem to operate still older databases for various reasons. And even if you think that you are safe, double check for any older databases in your environments. You MUST patch 12.1.0.1 and 11.2.0.3 and older databases before June 23, 2019. And just to be clear: June 23, 2019 is going to happen in less than 4 months.

You MUST patch 12.1.0.1 and 11.2.0.3 and older databases before June 2019

Photo by Dimitar Donovski on Unsplash

Who is NOT affected?

If you use the following Oracle database releases exclusively, you are NOT affected:

  • Oracle Database 12.1.0.2 and newer (including Oracle 12.2.0.1, Oracle 18c and Oracle 19c)
  • Oracle Database 11.2.0.4
  • Oracle Database 11.2.0.3 with at least Jan 2014 PSU/BP
  • Oracle Database 11.1.0.7 with at least Jul 2014 PSU/BP
  • Oracle Database 10.2.0.5 with at least Oct 2017 PSU and Patch 14121009 on top
  • On MS Windows:
    • 11.2.0.3 with at least Patch 29 (Feb 2014)
    • 11.1.0.7 with at least Patch 57 (Jul 2014)

And of course, if your databases don’t use database links, this issue may not affect you either.

But if you use database links to databases of releases below the ones I did mention, you must patch.
Now!

Or upgrade in some cases. Especially in cases where you use “buffer” databases such as connecting an Oracle 9i database to an Oracle 11.2.0.4 database in order to pull data from an Oracle 12.2.0.1 databases.

What is the technical background?

At any point in time, the Oracle Database calculates a “not to exceed” limit for the number of SCNs a database can have used, based on the number of seconds elapsed since 1988. This is known as the database’s current maximum SCN limit. When you open a database link between two databases, the SCN needs to be synced between the two. If one of the two databases is unpatched, then it can happen that the SCN increase needed in the unpatched database for this sync is beyond it’s allowed SCN rate or current max SCN limit. In this case the database link connection cannot be established.

This issue can arise after June 23, 2019.

If you need more information in addition to MOS Note: 2335265.1, you will find an excellent technical summary here on Job Oprel‘s blog:

And of course, Frits Hoogland has dug muuuuuch deeper and came around with this long post:

What are the patches implementing?

These recommended patches enable the databases to allow for a higher current maximum SCN limit. The rate at which this limit is calculated can be referred to as the “SCN rate” and these patches help allow higher SCN rates to enable databases to support many times higher transaction rates than earlier releases.

Please note that the patches only increase the max limit but the current SCN is not impacted. So, if all your databases don’t have any major change in transaction rate, the current SCN would still remain below the current maximum SCN limit and database links between newer (or patched) and unpatched databases would continue to work. The patches provide the safety measure to ensure that you don’t have any issue with database links independent of any possible future change in your transaction rate.

If this patch is not applied, the unpatched database will have a lower SCN rate or lower current max SCN limit.
The newer or patched databases will have higher SCN rate or higher current max SCN limit.

What is the risk of NOT patching?

You should be aware about potential database link issues in future and consider about upgrading the databases or not using database links with newer versions of databases . If you continue to have such database links after June 2019, you may get run-time errors during database link operations and you would need to disconnect those database links at that time.

What should you do now?

For owners of a large number of databases, across earlier versions, where you are not able to patch or upgrade and these databases use dblinks with very databases of newer releases, please contact Oracle Support immediately for guidance.

If you are in doubt, if you have older database releases still in use, please do the following:

  • Open a Service Request with Oracle Support and ask for guidance
  • You may check beforehand with the information provided on Frits Hoogland’s blog for SCN headroom
  • You may also use the Community Forum to discuss with the experts: Oracle Community Discussion

I really can’t give you advice on this. I can alert you about the issue. But clarification, advice etc need to come from Oracle Support.

Where do you find more information?

Here you’ll find a lot more information:

–Mike

PS: Please ignore the change from March 10, 2019 – here’s another addition as of Apr 16, 2019:

It turned out that a conflicting patch for Oracle 10.2.0.5 which was needed on top of the October 2017 PSU got re-released. Hence, with the combination of the October 2017 PSU for Oracle 10.2.0.5 plus Patch 14121009 on top of it, the issue is fixed as well.

I keep the below PS from March 10, 2019, for the records only – it is not correct anymore.

PS: An addition as of March 10, 2019:

Initially the blog post listed this release as not affected:

    • Oracle Database 10.2.0.5 with Jan 2017 PS

But in fact the patch is not included in this PSU. Hence, Oracle 10.2 is always affected by this issue. Even if you are on the highest patch level for 10.2.0.5. Sorry for the inconvenience. The MOS Note the information was taken from should have been corrected as well by now.

Share this: