【打补丁】为 Oracle 19.17.0 应用第一个 MRP（月度推荐补丁）

原创小小亮 2022-11-18

3360

几周前，我在博客中提到了我们停用 RUR 并发布 MRP（每月推荐补丁）的事实。现在是 11 月中旬，我可以向您展示为 Oracle 19.17.0 应用第一个 MRP 的过程。

Glenov Brankovic在Unsplash上拍摄的照片

您如何获得 MRP？

在我写这篇文章的时候，您只能在MOS 注释中找到 MRP：888.1 - 数据库主动补丁程序的主要注释– 但 MOS 注释中的链接/部分：555.1 – Oracle 数据库 19c 重要推荐的一次性补丁应该出现也很快。

MOS 注释：888.1 - 数据库主动补丁程序的主要注释

Oracle 数据库 19.17.0 的 MRP1 中有什么？

说到内容，包括这 7 个修复程序。

34737974/
├── 30691454
├── 33896423
├── 34333986
├── 34366627
├── 34538232
├── 34574048
├── 34724125
├── automation
├── bundle.xml
├── README.html
└── README.txt

其中 3 个来自MOS 注意：555.1，3个是重要的附加修复程序，1 个是针对第 3 方软件的安全修复程序。但是在我的博文下方_的库存如何告诉您您已应用 MRP 下找到进一步的描述？_.

如何应用 MRP？

首先，至关重要的是您要应用最新的 opatch，而且要事先进行冲突检查，正如我通常在我的季度博文中展示的那样，例如使用 2022 年 10 月的捆绑补丁修补我的所有环境. 由于 MRP 与捆绑在一起的一些一次性补丁没有什么不同，我认为您应该确保没有安装冲突的补丁。

冲突和空间检查

但是…令人惊讶…我最好之前研究过自述文件

$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Oracle Interim Patch Installer version 12.2.0.1.33
Copyright (c) 2022, Oracle Corporation.  All rights reserved.
PREREQ session
Oracle Home       : /u01/app/oracle/product/19
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/19/oraInst.loc
OPatch version    : 12.2.0.1.33
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-11-16_16-36-53PM_1.log
This command doesn't support System Patch.
OPatch failed with error code 21

所以最好阅读README。

以正确的方式为此 MRP 完成冲突检查

$ $ORACLE_HOME/OPatch/opatchauto apply -binary . -analyze -online
Oracle Home : /u01/app/oracle/product/19
OPatchAuto binary patching Tool
Copyright (c)2014, Oracle Corporation. All rights reserved.
OPatchauto Version : 13.9.5.0.0
Running from       : /u01/app/oracle/product/19
opatchauto log file: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/opatchauto_2022-11-16_16-40-23_binary.log
Patch selected: /home/oracle/34737974
Analysing this list of patches : 
[/home/oracle/34737974/33896423, /home/oracle/34737974/34333986, /home/oracle/34737974/30691454, /home/oracle/34737974/34538232, /home/oracle/34737974/34574048, /home/oracle/34737974/34366627, /home/oracle/34737974/34724125] ...
Analysis completed.
==Following patches were SUCCESSFULLY analyzed to be applied:
Patch: /home/oracle/34737974/33896423
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log
Patch: /home/oracle/34737974/34333986
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log
Patch: /home/oracle/34737974/30691454
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log
Patch: /home/oracle/34737974/34538232
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log
Patch: /home/oracle/34737974/34574048
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log
Patch: /home/oracle/34737974/34366627
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log
Patch: /home/oracle/34737974/34724125
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log
opatchauto SUCCEEDED.

准备好这可能需要一段时间，具体取决于您家中的补丁数量——我有很多。在我的 playground 环境中，应用从开始到结束花费了将近 12 分钟，这首先与依赖性检查有关，而且唯一的补丁应用本身也花费了 5 分钟。

你必须使用opatchauto吗？

对我来说完全是新闻，README没有谈论opatch而只是opatchauto。在上面您已经可以看到，我以前使用opatch对空间和冲突进行的预检查失败了。但我必须尝试是否至少可以将 MRP 与opatch一起应用。

这是我在使用opatch时收到的错误：

$ $ORACLE_HOME/OPatch/opatch apply
Oracle Interim Patch Installer version 12.2.0.1.33
Copyright (c) 2022, Oracle Corporation.  All rights reserved.
ZOP-51: The patch location is not valid for apply, because it doesn't have correct metadata, or it points to a patch directory. 
Argument(s) Error... Patch location is not valid for apply
Please check the arguments and try again.
OPatch failed with error code 135

但是我可以向下爬到每个子目录，并使用opatch分别安装每个补丁。当然，这不是补丁包的想法。但我想知道为什么我可以使用opatch安装 Data Pump Bundle 补丁——而新的 MRP 需要opatchauto。让我与我们的补丁机构核实一下——一旦我对此有更多了解，我将更新这篇博文。

所以总而言之，答案是（现在）：是的，你现在必须使用opatchauto，因为它是像系统补丁一样构建的。

Timur 问我是否尝试过opatch napply——但这也会失败，并显示“这不是系统补丁”错误消息。

你需要调用数据补丁吗？

再次，让我们查阅README。因为手动浏览所有补丁对您来说很痛苦，如果您没有在README中看到这一点：

注意：MRP 19.17.0.0.221115 不包含任何 SQL 更改，因此不需要在安装后运行 datapatch。对于未来的 MRP，这可能会改变。

如果你不小心运行了 datapatch 会发生什么？

$ $ORACLE_HOME/OPatch/datapatch -verbose
SQL Patching tool version 19.17.0.0.0 Production on Thu Nov 17 13:20:54 2022
Copyright (c) 2012, 2022, Oracle.  All rights reserved.

Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_21181_2022_11_17_13_20_54/sqlpatch_invocation.log

Connecting to database...OK
Gathering database info...done

Note:  Datapatch will only apply or rollback SQL fixes for PDBs
       that are in an open state, no patches will be applied to closed PDBs.
       Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation
       (Doc ID 1585822.1)

Bootstrapping registry and package to current versions...done
Determining current state...done

Current state of interim SQL patches:
Interim patch 33192694 (OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694)):
  Binary registry: Not installed
  PDB CDB$ROOT: Rolled back successfully on 19-JAN-22 10.14.44.327180 PM
  PDB PDB$SEED: Rolled back successfully on 19-JAN-22 10.14.44.347566 PM
Interim patch 33561310 (OJVM RELEASE UPDATE: 19.14.0.0.220118 (33561310)):
  Binary registry: Not installed
  PDB CDB$ROOT: Rolled back successfully on 20-JUL-22 09.17.02.767339 PM
  PDB PDB$SEED: Rolled back successfully on 20-JUL-22 09.17.02.812896 PM
Interim patch 34086870 (OJVM RELEASE UPDATE: 19.16.0.0.220719 (34086870)):
  Binary registry: Not installed
  PDB CDB$ROOT: Rolled back successfully on 08-NOV-22 11.05.34.788571 PM
  PDB PDB$SEED: Rolled back successfully on 08-NOV-22 11.05.36.745638 PM
Interim patch 34411846 (OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846)):
  Binary registry: Installed
  PDB CDB$ROOT: Applied successfully on 08-NOV-22 11.05.35.742058 PM
  PDB PDB$SEED: Applied successfully on 08-NOV-22 11.05.37.696607 PM
Interim patch 34734035 (MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187):
  Binary registry: Installed
  PDB CDB$ROOT: Applied successfully on 08-NOV-22 11.05.36.721787 PM
  PDB PDB$SEED: Applied successfully on 08-NOV-22 11.05.38.671338 PM

Current state of release update SQL patches:
  Binary registry:
    19.17.0.0.0 Release_Update 220924224051: Installed
  PDB CDB$ROOT:
    Applied 19.17.0.0.0 Release_Update 220924224051 successfully on 08-NOV-22 11.05.35.738500 PM
  PDB PDB$SEED:
    Applied 19.17.0.0.0 Release_Update 220924224051 successfully on 08-NOV-22 11.05.37.692881 PM

Adding patches to installation queue and performing prereq checks...done
Installation queue:
  For the following PDBs: CDB$ROOT PDB$SEED
    No interim patches need to be rolled back
    No release update patches need to be installed
    No interim patches need to be applied

SQL Patching tool complete on Thu Nov 17 13:21:25 2022

不用担心。没有任何事情发生，因为 datapatch 检测到不需要做任何事情。

库存如何告诉您已应用 MRP？

这其实有点令人失望。您将在下面看到它：

$ $ORACLE_HOME/OPatch/opatch lsinventory | grep -i "Patch Description" 
Patch description:  "Fix for bug 34724125"
Patch description:  "POD EEHO-DEV5 UNABLE TO SWITCHOVER ODS DB"
Patch description:  "AFTER GI PATCHING AND DB UPGRADE TO 19.16 SESSIONS ARE CONSUMING TEMPTABLESPACE."
Patch description:  "DNFS IO HANG  DURING STRESS TEST"
Patch description:  "AIM ORA-600 [KTUSCV1 CV BUF TOO BIG] - KTUSCV1"
Patch description:  "FLUSH OUT STALE ANTILOCKS AND CONVERT KCLCLS_2 AND  KCLANTILOCK_17 TO SOFT ASSERT"
Patch description:  "SYD  E1POD DBHOME PATCHING COMPLETELY HUNG WITH KPDBHASHTABLE_FIND MULTIPLE INSTANCE HANG"
Patch description:  "MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187"
Patch description:  "OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846)"
Patch description:  "Database Release Update : 19.17.0.0.221018 (34419443)"
Patch description:  "OCW RELEASE UPDATE 19.3.0.0.0 (29585399)"

目前您没有任何迹象表明已应用 MRP。您在我上面的列表中看到的 MERGE 补丁是 19.17.0 Data Pump Bundle 补丁，而不是 19.17.0 的 MRP1。在那里，您会发现前 7 个修复程序作为 MRP 应用的一次性修复程序。在我看来，这将使维护 MRP 变得困难。但是让我们看看我们可以在这里改进什么。

能否轻松回滚 MRP？

当然，我也必须尝试回滚。但我又遇到了一个惊喜。每个补丁都一个接一个地分别回滚。我猜 opatch 会检查我的库存，以了解它一遍又一遍回滚的每个补丁。所以要回滚 7 个补丁，每个补丁需要 6 分钟。现在您已经猜到了，在我的环境中回滚 MRP 花费了 40 多分钟。

$ $ORACLE_HOME/OPatch/opatchauto rollback -binary . -oh /u01/app/oracle/product/19 -target_type oracle_database
Oracle Home : /u01/app/oracle/product/19

OPatchAuto binary patching Tool
Copyright (c)2014, Oracle Corporation. All rights reserved.

OPatchauto Version : 13.9.5.0.0
Running from       : /u01/app/oracle/product/19

opatchauto log file: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/opatchauto_2022-11-17_10-56-30_binary.log

Target type : oracle_database

Patch selected: /home/oracle/34737974


Analysing this list of patches : 
[/home/oracle/34737974/33896423, /home/oracle/34737974/34333986, /home/oracle/34737974/30691454, /home/oracle/34737974/34538232, /home/oracle/34737974/34574048, /home/oracle/34737974/34366627, /home/oracle/34737974/34724125] ...

Analysis completed.

Rolling back the patches ...


Patches successfully rolled back.


==Following patches were SUCCESSFULLY rolled back:

Patch: /home/oracle/34737974/33896423
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log

Patch: /home/oracle/34737974/34333986
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log

Patch: /home/oracle/34737974/30691454
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log

Patch: /home/oracle/34737974/34538232
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log

Patch: /home/oracle/34737974/34574048
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log

Patch: /home/oracle/34737974/34366627
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log

Patch: /home/oracle/34737974/34724125
Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log


opatchauto SUCCEEDED.

之后我的库存看起来很好。

$ $ORACLE_HOME/OPatch/opatch lsinventory | grep -i "Patch Description"
Patch description:  "MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187"
Patch description:  "OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846)"
Patch description:  "Database Release Update : 19.17.0.0.221018 (34419443)"
Patch description:  "OCW RELEASE UPDATE 19.3.0.0.0 (29585399)"

所以总而言之，回滚工作正常，但需要相当多的时间，因为每个补丁都是单独回滚的——而且我猜库存检查会一遍又一遍地发生：

2022-11-17 11:30:32,257 INFO  [1] oracle.glcm.opatch.common.impl.SingletonPatch - /u01/app/oracle/product/19/inventory/oneoffs/34574048/etc/config/maintenance_alias.xml does not exist
2022-11-17 11:30:48,148 FINE  [1] oracle.opatch.util.perfmonitor.MethodTrackerObj - Error while ending the tracker. Message - null
2022-11-17 11:37:11,046 INFO  [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - Singleton  patch is found
2022-11-17 11:37:11,046 INFO  [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - Patch type found: SINGLETON_PATCH

在我的环境中为每个补丁花费整整 6 分钟。我们将对此进行进一步调查。

应用第一个 MRP 后的总结

我期待很多。我看到了一些改进的空间。当然，我们向负责构建 MRP 流程的小组发送了反馈。因此，让我们看看我们能得到什么，在 12 月中旬，一旦 19.17.0 的 MRP2 可用，我将再次发布有关 MRP 的博客。

如果您知道我必须自己手动下载 MRP 随附的 7 个修复程序、应用它们等 - 那么 MRP 对我来说可以方便地简化此过程。但我能感觉到您希望能够使用 opatch 而不是 opatchauto，并希望有一种更明显的方法来维护库存中的 MRP。

所以总的来说，MRP 是一件好事——但不是必须应用的——补丁包。让我们看看我们可以在 12 月中旬的下一次改进中获得哪些改进。

我们强烈建议您使用./runInstaller -applyRU … -applyOneOffs … 提供一个新家。丹尼尔昨天已经成功地测试了这个。他不仅在一个命令中应用了 19.17.0，还应用了 MRP1、Data Pump Bundle 补丁、OJVM 和最新的时区补丁。这样您就不必摆弄 opatchauto 和长时间运行的回滚。而且您不会随身携带完整的补丁清单，这会使每个补丁的应用时间越来越长。

原文标题：Applying the first MRP for Oracle 19.17.0
原文作者：Mike.Dietrich
原文链接：https://mikedietrichde.com/2022/11/17/applying-the-first-mrp-for-oracle-19-17-0/

最后修改时间：2022-11-18 12:35:23

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者