19.10.3 ? How is it possible to have a third RUR over a RU ?

Today, I was downloading all the patches released on the latest July-2021 CPU cycle, to check the differences and new features, as I quarterly do.

One of the things that surprised me, when I opened the Download Assitant MOS Note to get the 19c RURs:

And when opening this entry:

Shouldn't it be "19.10.2" ?!

Checking the README:

Just a few hours ago I had an AIOUG session where I said that would be impossible to have X.X.3 as the max RUR is 2 for any RU. Please forget it! =]

So, what happened here?

Checking Oracle Database 19c Release Update & Release Update Revision April 2021 Known Issues (Doc ID 19202104.9), we can see that 19.10.1, for both DB and GI, had some major issue and Oracle had to deploy a 19.10.2 just some days later:

So, 19.10.2 is actually Patch 32819074 which was delivered in May 23, 2021, to fix an issue in 19.10.1, and that could not wait until the next cycle.

In the list below you can see the bugs included in 19.10.2 that were not in 19.10.1:

    BUG_ID BUG_DESC
---------- ------------------------------------------------------------------------------------------
  31886745 DURING ROCE SWITCH REBOOT BOTH X8M-8 NODES EVICTED DUE TO GIPCD DECLARING NODE UNREACHABLE
  32044533 ORA-600 [OPIFCH2 ROWSETSEARLYRET] LOGGED IN DATABASE ALERT LOG
  32153396 EXACS EXADATA CLUSTER PROVISIONING FLOW FAILS TO STOP CLUSTERWARE STACK
  32191451 RDMA GET-KEY FAILS DUE TO INCORRECT NUMBER OF ACTIVE NETWORK DEVICES
  32425124 Fix for Bug 32425124
  32589990 TT23.1ASAN ORA ERRORS AT ROUTINE KFFFILERESIZE [KF F]

In summary, this is an exception. You will only see X.X.3 in those odd scenarios where a RUR needed to be replaced ASAP. Just pretend 19.10.1 is 19.10.2 and that 19.10.2 is 19.10.3. =]

And this is yet another reason to always go for the RU instead of the RURs.

+4