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.
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:
- Databases need to be patched before June 2019 (March 13, 2018)
- This blog post contains a lot of additional links at the end – please scroll down
- MOS Note: 2335265.1 – Recommended patching and actions for Oracle database versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019
- MOS Note: 2361478.1 – ANNOUNCEMENT: Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019
- Oracle Community Discussion – Patching Requirement
- Job Oprel’s blog post
- Frits Hoogland’s blog post
–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.
Hello Mike!
I know this could be a stupid question, but I decide to raise it anyway.
Does this all mean that all 11g XE installations are affected by this issue (11g XE for Linux and Windows was based on 11.2.0.2)? And that there is no other possibility to overcome it, but to migrate them to the newer 18c XE?
Hi Denis,
it’s a very valid question. When you connect to or from an 11.2.0.2 XE database to a patched one, for instance an 11.2.0.4 SE2 database, then you’ll be potentially affected.
Your upgrade path would be:
expdp from current XE
download new 18c XE for either Win or Linux (see the blog here)
impdp into an 18c XE
That’s it.
Cheers,
Mike
Hi Mike ,
We have Oracle 11g and 12c databases, some are on Exadata.
Since Oracle has changed the versioning model (one version per year), I would like to know what is the right/best strategy for managing the obsolescence of our databases and the migration to 18c and 19c.
Best regards.
GD.
GD,
not sure about your question. We changed the release numbering but 18c is 12.2.0.2, and 19c will be 12.2.0.3.
Hence, there’s not much of a change right now. We expect most software vendors to certify on 19c as this is the long term support release going until 2026.
Please see the slide deck about the release strategy on mikedietrichde.com/slides
This will give you more insights.
Thanks,
Mike
Hi Mike,
you stated recently, in a quick addition, that there’s no PSU available for 10.2.0.5. The first docs from Oracle stated that a special PSU (10.2.0.5.171017, which means OCT-2017, and not JAN-2017) would be available.
Accordingly to the MOS notes 2335265.1 and 2361478.1 (checked today) this PSU (along with interim patch 14121009) would still correct the problem in 10.2.0.5.
Easy links:
https://support.oracle.com/epmos/faces/DocContentDisplay?id=2335265.1
https://support.oracle.com/epmos/faces/DocContentDisplay?id=2361478.1
So, these MOS notes still state 10.2.0.5 as a “patchable” version for the 23-JUN db_link armageddon.
Best regards,
Luis Santos
Luis,
I’m puzzled now as well. Support experts told me that there’s no such patch for 10.2.0.5. That’s why I made the note in March on the blog post.
But now I read the note again – and indeed it has a patch.
Let me check that – and thanks for bringing this to my attention. I will update the blog post as soon as a receive a clarification.
Thanks (and sorry if I misinformed you – not my intention, I just reproduce information in this case)
Mike
Luis,
again big thanks – I could clarify and update the blog post.
Here’s what has happened:
1) The initial MOS document proposed that 10.2.0.5 with PSU xyz and patch abc would fix the issue
2) I’ve got alerted by support people that the MOS note is wrong, the single patch conflicts – and hence, can’t be applied.
3) Now based on your finding, I realized that the conflicting Patch 14121009 which is needed on top of the Oct 2017 PSU for 10.2.0.5 works now and can be applied.
Hence, there’s a fix available (except on Windows) for 10.2.0.5 as well.
Thanks again!
Cheers,
Mike
Thanks for your kindly reply, Mike.
There is new news! If you go the download page for OCT-2017 PSU for 10.2.0.5, aka patch 26493118, you will not the following message:
This Patchset has been Superseded.
Reason
Patch 26925212 is a super set of patch 26493118
Here is the link: https://support.oracle.com/epmos/faces/PatchDetail?&patchId=26925212
But, strangely, in the best DOC for the 23-JUN db_link armageddon (Doc ID 2361478.1, which was updated on 5-Apr-2019 with this important note: “Added patch details on top of 10.2.0.5”) it still recommends the old 26493118/OCT-2017 patch…
This is very weird. And we have just one month and 10 days up to the armaggedon day.
I was thinking if Oracle has forgot to update the DOC ID 2361478.1.
And if the newer, updated PSU JUL-2018, would include Patch 14121009, making it the only necessary patch to get rid of the db_link SCN interconnect problem on old 10.2.0.5 version.
Luis,
I’m pretty sure “somebody” has forgotten the update – and I’ll send an email to the appropriate people while I write this to you.
Thanks and sorry for the inconvenience!
Mike
Luis,
here’s the “official” statement – the note should be more clear now:
1. Patch 26925212 supersedes 26493118 in PSU terms
2. BUT … SCN fixes were made only on 26493118.
3. Patch 26925212 does not include the fix. It was specifically built for MDS customers and cannot be provided to all customers
4. SCN fix customers should use 26493118
This has been adeed:
==> Note: For 26493118, you will get a message that “This Patchset has been Superseded. Reason: Patch 26925212 is a super set of patch 26493118″, however for this particular fix you need to use 26493118 only. So please ignore this message and use 26493118.”
Cheers,
Mike
Mike, thanks again for all your work and support.
“Patch 26925212 does not include the fix. It was specifically built for MDS customers and cannot be provided to all customers”
But the fact that an older PSU includes and a fix, and its superseded not, does not make sense…
I think that the truth is because the single oneoff patch 14121009, which is also needed to fully address the problem, has been released for eight platform for combined use with PSU 10.2.0.5.171017 aka 26493118. But for only two platforms (Linux x86-64 and HP-UX Itanium) for PSU 10.2.0.5.180717 aka 26925212.
One of them, Linux x86-64, just last monday!
It seems that Oracle was furiously working to get 14121009 ready for PSU 10.2.0.5.180717, but it failed.
And decided to keep with older 10.2.0.5.171017, where 14121009 was already avaiable to more (probably all) platforms.
Luis,
it may look like that but in fact there are other reasons I can’t comment here.
Again, sorry for any inconvenience!
Cheers,
Mike
Hi,
We have a Linux server which is installed ASM 12.2.0.1 and there are 3 DB on it.
2 of them are 11.2.0.4 version of DB and 1 oftem 12.2.0.1.
It says that we need extendent support for the downloading the 11.2.0.4 PSU so I am not going to apply this patch.
My question is : If I apply combo patch for the ASM and DB which is 12.2.0.1, then would be any problem for 11.2.0.4 DB ?
Do you suggest that I should apply 12.2.0.1 patch ?
I am sure the exact effect.
Regards,
Ferit.
Ferit,
I always suggest adding important patches. And as you will patch your GI Home, and your DB 12.2.0.1 home, the 11.2.0.4 home will remain untouched (and without that patch).
Just one thing I disrecommend: Don’t use the COMBO patches but download the separate patches for GI as well as for the Database homes. Just my own experience – makes it a bit more controllable for me.
Cheers,
Mike
Has anyone experienced the issue?
This sounds to me like “2012 the end of WORLD” from the Mayas calendar
No Mayas mystic involved here – it’s reality.
Mike
I am trying to install GI 19.14 and with this cluster
11.2.0.3
11.2.0.4
12.2.0.1 databases
I could setup 11.2.0.3 and 12.2.0.1 but when I try to install 11.2.0.4 it behaves like mutually exclusive with 11.2.0.3
Is there any way to setup 11.2.0.3 and 11.2.0.4 within same cluster?
Hi Hakan,
I fear that 11.2.0.3 may cause you a lot of headache.
It is out of any bug fixing support since almost exactly 7 (!!) years now.
Cheers
Mike