When you patch, please use UPDATES – and not REVISIONS

I can just repeat what I’m saying not for almost a year: When you patch, please use UPDATES – and not REVISIONS. Updates (or Release Updates – short: RU) and Revisions (or Release Update Revisions – short: RUR) are patch bundles for the Oracle Database since Oracle 12.2.0.1. There are no PSUs (Patch Set Updates) anymore. And Revisions are not the same as PSUs.

When you patch, please use UPDATES – and not REVISIONS

One of the reasons why we recommend Updates, and not Revisions, simply is: Updates keep you more current whereas Revisions will let you miss a lot of fixes.

In Oracle 18c and on ward the 3-digit notation should ideally very easy to understand.
3-digits mean: Year.Update.Revision, for instance 18.5.1.

You see the usual quarterly patching months April, July, October, January and so on.

• The production release 18.1.0. does not get any Revisions
• But in April we did release 18.2.0, the first Update
• As there’s no Revision for the production release there won’t be an 18.1.1 in April
• In July the second Update will be release: 18.3.0
• At the same time in July the first Revision will be release – but for the Update of April, 18.2.0. The July Revision will be 18.2.1 meaning: Oracle 18, first Update, first Revision
• Then in October we will release the third Update 18.4.0, the first Revision 18.3.1 for the July Update and the second Revision 18.2.2 for the April Update
• There won’t be a third revision for an Update, thus no 18.2.3 will be released

It now becomes obvious why we don’t recommend Revisions. With the 18.2.2 Revision in October you sit on the Update of April which is six months old already. And you are not only hanging back in patches, you also introduce a variety to patching which is not necessary.

How does this translate to Oracle 12.2.0.1

To be honest, Roy and I have had numerous discussions and calls about the new release model. But I never thought that it will introduce such a strange look&feel to Oracle 12.2.0.1 patching. But of course, Updates and Revisions are not an invention for Oracle 18c. They exist in Oracle 12.2.0.1 as well.

Rodrigo Jorge highlighted such an interesting case to me the other day – and I followed also some twitter discussions which ended so far with the clear recommendation by external experts: Stay away from Revisions, use Updates. Makes your life much easier.

It all starts with MOS Note: 756671.1 – Master Note for Database Proactive Patch Program. You can find the different bundles from April 2018 for the Database and Grid Infrastructure listed there:

To me the notation is a bit strange: When it says (line 2) “Database Oct2017 Release Update Revision 12.2.0.1.180417” this sounds wrong at first sight. Especially as it has April 17, 2018 mentioned not only in the first column, but also at the end of the patch notation “12.2.0.1.180417“.

The Secret

• Line 1:
  April 18 Update
  ==> Database Release Update 12.2.0.1.180417 – Patch 27674384
  
• Line 2:
  Revision 2 on top of  October 17 Update
  ==> Database Oct2017 Release Update Revision 12.2.0.1.180417 – Patch 27427077
• Line 3:
  Revision 1 on top of January 18 Update
  ==> Database Jan2018 Release Update Revision 12.2.0.1.180417 – Patch 27670953

The Schema

It gets more obvious when I transfer this into the above schema picture but exchange 18c with 12.2.0.1:

All clear? No, not yet? I didn’t implement a copy&paste error here – I used just the notation of the patch. And I added a type column. When I remove the October and January columns and copy&paste the notation from MOS Note: 756671.1, then you see what I mean:

Do you recognize that the order from the note has been changed? It lists the Revision 2 before Revision 1. I put it now into the correct order. And well, when you would click on the patch number for the Revision 1 in April, 27670953, it will lead to a dead end street as Rodrigo Jorge pointed out. The correct number seems to be: Patch 27856791. This one is mentioned in the first table of the note, but the note’s owner must have forgotten to exchange it in the 12.2.0.1 table as well. Update: I received a note that the wrong patch number should be corrected soon.

The Confusion

The note has unfortunately more failures. When you want to apply for instance Revision 2 (Patch 27427077) it guides you to the download for the Grid Infrastructure – System patch (Patch 27696758: GI OCT 2017 RELEASE UPDATE REVISION 12.2.0.1.180417). But, when you look at the readme, you will see that it contains the Revision 2 I’m looking for: 27427077. All fine, just a bigger download (1.1GB in this case).

The observation you may have as well: There’s a mix of patches of different dates. And I can’t answer why this is the case. Please remember: I’m not the Product Manager for Patching neither do I work in this area. The OCW (Oracle Cluster Ware) patch seems to be the Revision 1 based on the October 2017 Update.

But when you apply now the Revision you may recognized the same strange thing Rodrigo has seen as well: In REGISTRY$SQLPATCH‘s DESCRIPTION column a patch appears now as DATABASE OCT 2017 RELEASE UPDATE REVISION 12.2.0.1.0(ID:180417.2) . And I believe this added “1” or “2” to the ID should indicate the differentiation between the Revisions as they all sail under the flag “180417” as they got released this day. Just my naive interpretation.

Sounds strange?

I can just repeat myself:
When you patch, please use UPDATES – and not REVISIONS

Especially in Oracle 12.2.0.1.

–Mike

PS: And I don’t know why Rodrigo has “180411” in his REGISTRY$SQLPATCH. An SR should clarify this.
Update: This will investigated by the owners of the patching process. No SR needed.