Some additional information regarding the Oracle 19.14.0 RUs

You may have read my previous blog post about patching all my environments to the January 2022 patch bundles. But since I do this in a very simple non-RAC, non-GI environment, I may not see issues you may have encountered. Some people commented – and I would like to share Some additional information regarding the Oracle 19.14.0 RUs . Still, please, this is NOT a collection of all open issues. I just see this blog post as a summary of the issues I have seen and/or heard about so far.

Some additional information regarding the Oracle 19.14.0 RUs

Photo by Josh Hild on Unsplash

555.1 is one of the most important MOS notes

At first, before you read the about the topics below, make sure you have checked one of THE most important MOS notes:

And please, add it to your favorites as well (the upper left star in the MOS note). It lists the most important issues for each of the patch bundles and the fixes you should consider to put on top of any of them.

ACFS RU issue

Important information:
The Development team tried to reproduce the below case but didn’t succeed. In addition, please be aware that the initial setup was a supported combination (kernel version <=> ACFS version) while the result at the end isn’t a supported mix of kernel and ACFS. So this isn’t a solution you should attempt.

Nariman reported this issue to me via the blog (and thanks for sharing it with me including the solution). He had a significant problem with applying 19.14.0 to his environment. At first, his apply of 19.14.0 failed in the CRS part already. Then he tried to install each of the sub-components of the patch bundle separately and found that the fail is caused by the ACFSRU, patch 33534448.

The key error message was:

2022/01/20 12:46:28 CLSRSC-400: A system reboot is required to continue installing.

Argument “” isn’t numeric in numeric ne (!=) at /u01/app/grid/19/grid/lib/acfslib.pm line 347.

But the system reboot did not solve the problem.

The solution finally as Nariman told me was:

As soon as I updated kernel, it was upgraded from “4.18.0-305.19.1.el8_4.x86_64” to “4.18.0-348.12.2.el8_5.x86_64” and the patching went perfect!

I wouldn’t have been considered a kernel update as a potential solution – but very happy that it fixed it.

GI Patching Alert: CRS-5037

This is something you can find already in the comments section of Patching all my environments with the January 2022 Patch Bundles. And at the same time, my dear ACS colleague Thomas alerted me on slack as well about this issue.

In this note you can read that with 19.14 GI, user-defined database services may fail to start with error CRS-5037: Database does not have the required fix for bug ‘31143870’. Not everybody is going to see this issue. The MOS note explains that only configurations satisfying all 3 conditions listed below may experience the issue:

  • Grid Infrastructure Release “19.14”
  • Contains database(s) running on “RDBMS Releases <= 18c” and/or “RDBMS Releases 19.3 to 19.10 without Patch 31143870”
  • Has one or more user-defined services NOT created on PDB. i.e. “crsctl stat res ora.db_name.service_name.svc -f | grep PLUGGABLE_DATABSE” will show null value for PLUGGABLE_DATABSE key such as:
    $ crsctl stat res ora.database_name.service_name.svc -f | grep PLUGGABLE_DATABASE
    PLUGGABLE_DATABASE=
    $

     

And a solution is to apply patch 33733953 beforehand.

Meanwhile, this issue got added to MOS Note: 555.1 as well:

Some additional information regarding the Oracle 19.14.0 RUs

Gridsetup SwitchGridHome fails

This is actually an issue which came up with 19.13.0 already. You may encounter it only when you do out-of-place GI patching. When you patch in-place you won’t see this bug. Still, this isn’t fixed in 19.14.0 yet but only from 19.15.0 onward.

It is labeled as:

  • Bug 33601195 : GRIDSETUP -SWITCHGRIDHOME OOP – ROOT.SH GENERATED INCORRECTLY

And there are two good news for you. At first, you can download a patch 33601195 on top of 19.13.0 if you plan to patch GI out-of-place to 19.13.0. But as of now I can’t see any patch on top of 19.14.0 yet.

What’s the other good news? Well, you can use this proven workaround:

  1. Node_1: Execute $ORACLE_HOME/root.sh
  2. Node_1: scp $ORACLE_HOME/crs/config/rootconfig.sh Node_2:$ORACLE_HOME/crs/config/rootconfig.sh
  3. Node_1: scp $ORACLE_HOME/crs/install/crsconfig_params Node_2:$ORACLE_HOME/ crs/install/crsconfig_params
  4. Node_2: Execute $ORACLE_HOME/root.sh

And of course, if you have more than 2 nodes, you must repeat the copy operation to the other nodes as well and execute root.sh there, too.

Patching Duration

Several people over the past months complained about patching duration. If this applies to the opatch or opatchauto part of the patching, please open an SR. As I commented already in Patching all my environments with the January 2022 Patch Bundles, it takes a significant long time in my 19c environment while the 21c or the 12.2.0.1 environments get patches fairly quick. I see minute-long waits during the opatch process but I haven’t found either the root cause or a solution yet. Opatch 28 (6880880) is supposed to fix one of these issues – but since I used opatch 28 for my environments, I haven’t seen it completing faster.

For the datapatch part of the patching, I will have another blog post within the coming days.

Further Links and Information

–Mike

 

Share this: