Strange blog headline, isn’t it? Intentionally. Peter Lehmann mailed me a question – and asked more or less: Why is the October Patch Bundle from July? Sounds strange? It is strange …
Strange notation
Peter wanted to download the most recent patch bundle for Grid Infrastructure from October. And he found patch 28507693:
But he was wondering about the headline having the date of October 18, 2018 together with JUL 2018.
How does this make sense??
Flashback
When you flash back to the day when we introduced “Updates” (RU) and “Revisions” (RUR) you may remember that we release quarterly “Updates” and “Revisions” whereas a Revision is based on a previous Update adding just security and regression fixes.
See here:
Hence, in this case you are looking at the Revision 1 of the July 2018 Update for GI 12.2.0.1.
This is why the October patch has July in the name
Actually I followed the internal discussion about how to name these patches and there’s no perfect solution. I think it would be more obvious when the patch tag line would display RU or RUR at first instead of a long phrase where you easily overlook the “Revision” keyword.
The solution
My solution is using the Patch Download Advisor note knowing that it is not updated the day the patches get released.
- MOS Note: 2118136.2
Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases
Then your choice is much easier – and you won’t access accidentally the Revision when you are looking for the Update:
There’s an GI Update for October 2018 and a GI Revision 1 for October based on the GI Update of July adding only regression and security fixes.
Sorry for the strange notation. If you have a bullet-proof idea how to better name the patches to avoid confusion, I’ll happily explain it to the owners of the process.
–Mike
Mike,
While discussing patching, I have a question. The Oct 2018 CPU addresses a critical vulnerability CVE-2018-3259. We are on Exadata and the QFSDP for Oct 2018 was released today (it was released on Wednesday, withdrawn and re-released today. The file checksums between Wednesday and Friday release are different, something has changed).
There is not enough time to download the patch, test it and apply it as we had already conveyed the dates for applying the Jul 2018 CPU patch starting Oct 30. So, we have no option but to apply the July 2018 CPU patch.
My question is, instead of applying the OJVM patch from July 2018, is it possible to apply just the OJVM patch from Oct 2018? The GI and DB patch will still be at Jul 2018. Is this supported? Would the Oct 2018 OJVM patch have the fix for CVE-2018-3259?
Thanks,
Arun
Hi Arun,
yes, this is possible – you can apply the OJVM RU only or in a different version.
I don’t see why this shouldn’t be supported as we offer separate downloads.
Cheers,
Mike
Hi Mike,
Why not just call it 12.2.0.1.180717-R1 ?
Including “181016” (October) in the name for something that is relevant only for the July RU makes it really confusing.
Felipe
Thanks 🙂
Hi Mike,
I’m not sure if this idea is bullet proof, at least it comes from Oracle:
In Version 18, there I can distinguish
Patch 28659165: GI RELEASE UPDATE 18.4.0.0.0
Patch 28660077: GI RELEASE UPDATE REVISION 18.3.1.0.0
Patch 28702032: GI RELEASE UPDATE REVISION 18.2.2.0.0
Similar to the the current (18.x) Release Numbers Oracle can define for 12.2 (without breaking previous numbering schema):
Third numeral: RU
Fourth numeral: RUR
So when we take March 2017 as release date of 12.2,
we can now have
12.2.7.0.0.181016 for Patch 28714316: GI OCT 2018 RELEASE UPDATE 12.2.0.1.181016
and
12.2.6.1.0.181016 for Patch 28507693: GI JUL 2018 RELEASE UPDATE REVISION 12.2.0.1.181016
Maybe this helps to make evolution of RU and RURs as visible as it is for 18.
hth,
Martin
Hi Martin,
the 3rd number is unfortunately protected by middleware as far as I remember.
At least for the releases before 18c.
I’ll collect feedback and then we’ll see if we can ease this wonderful experience a bit 🙂
Cheers,
Mike