The newest patching surprises – and how to fix some of them

Well, there is no Product Manager for patching. And I’m glad that I’m not in this position. But thanks to all of you, internally and externally, who share your findings with me. In this blog post I’d like to inform you about the newest patching surprises – and how to fix some of them.

Patch apply without confirmation?

Peter Lehmann informed me about this a few weeks ago. Peter told me that he patched systems with the July 2019 RU for Oracle 12.2.0.1 and recognized that the patch installed with opatch without waiting for confirmation. It looked as somebody has silently switched it to silent install.

In between, Peter pointed me to this discussion on the My Support Community Forum:

• https://community.oracle.com/message/15413552#15413552With the Oracle 18.7.0 RU the same thing seems to happen:
  “During apply of this patch, I did notice:

   $ opatch apply Oracle Interim Patch Installer version 12.2.0.1.17 (...)
 Do you want to proceed? [y|n] Y (auto-answered by -silent)
 User Responded with: Y
 All checks passed.

  I did not enter the -silent option”

On behalf of Peter, I filed Bug# 30171495 - 12.1.0.2 JULY 2019 DB BP PATCH 29496791 INSTALLS DIRECTLY WITHOUT WAITING FOR USER CONFIRMATION not knowing at this point that this has nothing to do with the RU itself.

The Explanation

It took a while until a solution (or to be more precise: explanation) was given – but I was a bit surprised as this hasn’t been documented. It will be documented soon I guess.

If OPatch detects the OOP mode (patching busy files), then it comes to silent mode. This is a new feature from OPatch. Before this, OPatch requires all processes to be down before it could continue. That was the reason why OPatch did always ask for confirmation first.

Now with this new feature, OPatch can handle the patch apply even when the database processes are up and running. OPatch can patch busy files. From now on, users don’t need to worry about shutting down the processes before patching – this prompt is no longer needed.

Hence, actually this is a cool new feature. And it turns out that this feature is enabled already in opatch versions 16 and 17.

And of course, nothing needs to be changed or fixed.

Incorrect Patch Level Metadata?

The next topic got sent to me by Thomas Gorsitzke, one of our very experienced Principal Solution Engineers in Oracle Germany (thanks for sharing, Thomas!). And this issue can happen to everybody who applied one of the following patch bundles:

• Oracle Database 19.4.0.0.0 DBRU
• Oracle Database 19.3.1.0.0 DBRUR
• Oracle Database 19.3.0.0.0 DBRU

19.3.0 and 19.3.1 should potentially happen only rarely in some Exadata environments. But I guess, many applied 19.4.0 already. As the patch apply could cause incorrect metadata, either further on-off patch or rollback attempts may fail.

You may see this message when you try to apply another patch on top – or rollback it:

"Skip patch <bug#> from list of patches to apply: This patch is not needed.”

What you need to do in case you have installed 19.3.0, 19.3.1 and/or 19.4.0:

You must download the script check_patch_level.sh from this MOS Note:

• MOS Note: 2575299.1 – Potential Impact to Database 19c One-off patches Due to Incorrect Patch Level Metadata

If it identifies any faulty patch, you must rollback them, download them again from MyOracle Support and reapply them.

And please, don’t shoot the messenger!

–Mike