好的，我答应写更多关于补丁速度的文章。这篇博文将只是针对数据补丁速度的根帖子。我还将链接到我之前写过的博客文章，但也会分享在第一阶段可能并不明显的知识。总体主题将是如何加快数据补丁速度——以及更多信息。
什么是数据补丁
让我从底层开始解释什么是数据补丁以及它存在的原因。
当您还在使用 Oracle Database 11g 时，您可能想知道 datapatch 到底是什么。当然，我希望你不再使用 11g。因此，大多数读者之前已经使用过数据补丁。它基本上是为了满足多租户环境中的软件/数据库修补，在这种环境中，您不仅需要调整单个数据库。即使在只有一个 PDB 的单租户环境中，您也需要将 SQL 和 PL/SQL 更改应用到 CDB$ROOT 以及 PDB 和 - 只读 - PDB$SEED。
“datapatch 是一种修补工具，它将 SQL 和 PL/SQL 更改应用于所有数据库和/或容器并更新数据字典。”
您可以在$ORACLE_HOME/OPatch目录中找到数据补丁。对于每个新版本的 opatch，您可能还会获得一个新版本的 datapatch。
但是您是否曾经在编辑器中打开过数据补丁？它相当短，基本上只这样做：
$ORACLE_HOME/sqlpatch/sqlpatch $@
现在，当您打开 sqlpatch 时，您可能不再奇怪它只会调用另一个“伙伴”来做实际工作：
$ORACLE_HOME/perl/bin/perl -I$ORACLE_HOME/sqlpatch -I$ORACLE_HOME/rdbms/admin -I$ORACLE_HOME/sqlpatch/lib $ORACLE_HOME/sqlpatch/sqlpatch.pl $@
所以现在我们更接近了。它实际上是一个 perl 脚本。通过所有这些步骤，将设置正确的环境和修补参数，然后进行日志记录和清理。
但归根结底，它利用 SQL*Plus 来执行脚本和语句。
跟踪补丁
数据补丁的核心组件之一是它跟踪数据库中的补丁。在这个博客上，您可以找到几个脚本来监控数据库中的数据补丁操作和补丁历史记录。
这是它在我的一个环境中的样子：
CON_ID ACTION_TIME PATCH_ID PATCH_TYPE ACTION DESCRIPTION SOURCE_VERSION TARGET_VERSION
_________ ______________ ___________ _____________ ___________ ________________________________________________________ _________________ _________________
1 2019-04-28 29517242 RU APPLY Database Release Update : 19.3.0.0.190416 (29517242) 19.1.0.0.0 19.3.0.0.0
1 2019-10-16 30125133 RU APPLY Database Release Update : 19.5.0.0.191015 (30125133) 19.3.0.0.0 19.5.0.0.0
1 2020-01-21 30557433 RU APPLY Database Release Update : 19.6.0.0.200114 (30557433) 19.5.0.0.0 19.6.0.0.0
1 2020-04-15 30869156 RU APPLY Database Release Update : 19.7.0.0.200414 (30869156) 19.6.0.0.0 19.7.0.0.0
1 2020-07-15 31281355 RU APPLY Database Release Update : 19.8.0.0.200714 (31281355) 19.7.0.0.0 19.8.0.0.0
1 2020-10-21 31771877 RU APPLY Database Release Update : 19.9.0.0.201020 (31771877) 19.8.0.0.0 19.9.0.0.0
1 2021-01-20 32218454 RU APPLY Database Release Update : 19.10.0.0.210119 (32218454) 19.9.0.0.0 19.10.0.0.0
1 2021-04-21 32545013 RU APPLY Database Release Update : 19.11.0.0.210420 (32545013) 19.10.0.0.0 19.11.0.0.0
1 2021-08-09 32904851 RU APPLY Database Release Update : 19.12.0.0.210720 (32904851) 19.11.0.0.0 19.12.0.0.0
1 2021-12-15 33192793 RU APPLY Database Release Update : 19.13.0.0.211019 (33192793) 19.12.0.0.0 19.13.0.0.0
1 2021-12-16 33192694 INTERIM APPLY OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694) 19.13.0.0.0 19.13.0.0.0
1 2022-01-19 33192694 INTERIM ROLLBACK OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694) 19.14.0.0.0 19.14.0.0.0
1 2022-01-19 33515361 RU APPLY Database Release Update : 19.14.0.0.220118 (33515361) 19.13.0.0.0 19.14.0.0.0
1 2022-01-19 33561310 INTERIM APPLY OJVM RELEASE UPDATE: 19.14.0.0.220118 (33561310) 19.14.0.0.0 19.14.0.0.0
2 2019-04-28 29517242 RU APPLY Database Release Update : 19.3.0.0.190416 (29517242) 19.1.0.0.0 19.3.0.0.0
2 2019-10-16 30125133 RU APPLY Database Release Update : 19.5.0.0.191015 (30125133) 19.3.0.0.0 19.5.0.0.0
2 2020-01-21 30557433 RU APPLY Database Release Update : 19.6.0.0.200114 (30557433) 19.5.0.0.0 19.6.0.0.0
2 2020-04-15 30869156 RU APPLY Database Release Update : 19.7.0.0.200414 (30869156) 19.6.0.0.0 19.7.0.0.0
2 2020-07-15 31281355 RU APPLY Database Release Update : 19.8.0.0.200714 (31281355) 19.7.0.0.0 19.8.0.0.0
2 2020-10-21 31771877 RU APPLY Database Release Update : 19.9.0.0.201020 (31771877) 19.8.0.0.0 19.9.0.0.0
2 2021-01-20 32218454 RU APPLY Database Release Update : 19.10.0.0.210119 (32218454) 19.9.0.0.0 19.10.0.0.0
2 2021-04-21 32545013 RU APPLY Database Release Update : 19.11.0.0.210420 (32545013) 19.10.0.0.0 19.11.0.0.0
2 2021-08-09 32904851 RU APPLY Database Release Update : 19.12.0.0.210720 (32904851) 19.11.0.0.0 19.12.0.0.0
2 2021-12-15 33192793 RU APPLY Database Release Update : 19.13.0.0.211019 (33192793) 19.12.0.0.0 19.13.0.0.0
2 2021-12-16 33192694 INTERIM APPLY OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694) 19.13.0.0.0 19.13.0.0.0
2 2022-01-19 33192694 INTERIM ROLLBACK OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694) 19.14.0.0.0 19.14.0.0.0
2 2022-01-19 33515361 RU APPLY Database Release Update : 19.14.0.0.220118 (33515361) 19.13.0.0.0 19.14.0.0.0
2 2022-01-19 33561310 INTERIM APPLY OJVM RELEASE UPDATE: 19.14.0.0.220118 (33561310) 19.14.0.0.0 19.14.0.0.0 我不想深入了解输出的细节，但您很容易认识到视图CDB_REGISTRY_SQLPATCH跟踪所有更改，不仅是 RU，还包括临时（一次性）补丁。
请始终做两件事：
- 不要访问 DBA_REGISTRY_SQLPATCH 而是访问 CDB_REGISTRY_SQLPATCH 因为您的脚本也会在 CDB 环境中显示正确的信息
- 始终设置alter session set “_exclude_seed_cdb_view”=FALSE; 因为否则您将错过 PDB$SEED - 这可能会以一场真正的噩梦告终。即使在非 CDB 环境中使用此下划线也无害。如果您想知道为什么默认设置为 FALSE，请打开 SR 并使用此默认参数设置参考任何已打开的错误。
您还可以在上面的脚本中添加一个ACTION_TIME分隔符，以仅查看过去 6 个月的补丁操作，特别是因为 19c 很可能有更长的寿命。请注意，列表首先按CON_ID排序。您也可能更喜欢对ACTION_TIME进行排序。
总之，您的数据库知道它何时被数据补丁处理过。
如果您忘记运行数据补丁怎么办？
这是我们不时听到的一个常见问题——实际上我们有时会看到。你用 opatch 很好地打了补丁，但是有人忘了运行 datapatch。
起初，有人忘记运行数据补丁这一事实很糟糕。这意味着您的数据库使用二进制补丁运行，但缺少补丁的 SQL 和 PL/SQL 部分。当然，有些补丁没有 SQL 或 PL/SQL 表示。通常优化器修复就是这样的例子。问题的修复是在二进制文件中，不需要在字典中进行调整。相反的是数据泵。通常在 SQL 和 PL/SQL API 中有一个对应部分。
所以请确保运行：
$ORACLE_HOME/OPatch/datapatch -verbose
作为将二进制补丁应用到系统时的标准操作。
但是，如果您无缘无故地再次意外运行它，看看会发生什么。完全不用担心，它承认它无关紧要。
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: Installed
PDB CDB$ROOT: Applied successfully on 19-JAN-22 10.14.44.331372 PM
PDB PDB$SEED: Applied successfully on 19-JAN-22 10.14.44.350816 PM
Current state of release update SQL patches:
Binary registry:
19.14.0.0.0 Release_Update 211225122123: Installed
PDB CDB$ROOT:
Applied 19.14.0.0.0 Release_Update 211225122123 successfully on 19-JAN-22 09.48.19.540225 PM
PDB PDB$SEED:
Applied 19.14.0.0.0 Release_Update 211225122123 successfully on 19-JAN-22 09.48.19.756424 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 Mon May 30 11:35:36 2022然后它成功停止，没有对您的数据库和容器进行任何处理。
滚动还是不滚动，这是个问题
我需要提到一个非常重要的附加信息。
您可能想知道为什么某些补丁（例如 Data Pump 补丁）通常不包含在发布更新 (RU) 补丁包中。简单的解释是，RU 中的补丁应该是“ RAC rolling and standby-first ”。但只要补丁有 SQL 和/或 PL/SQL 部分并调整 API，只要无法阻止所有实例对 API 的访问，就存在风险。因此，此类补丁被排除在补丁包之外。
因此，在集群的哪个节点上调用 datapatch 也无关紧要。但是您只需要在一个节点上调用它，而不是在每个节点上调用它，因为您修补了数据库的字典。
启动升级？
这是最古老的神话之一。
您的数据库或 PDB 不必处于STARTUP UPGRADE模式。相反，正常的STARTUP就足够了。但是，您的 PDB 是开放的，这一点非常重要。无法调整已关闭的 PDB。
这就是为什么我们总是建议使用SAVE STATE命令来确保在您关闭 CDB 后自动打开您的 PDB。当然，在 RAC 环境中，您可以通过资源设置来实现这一点。
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)前段时间我写了一篇关于是否需要启动升级的博客文章。
重复我自己，这是不需要的。我们与修补团队一起更正了 OJVM README。
记录信息
现在，当您深入挖掘时，您可能会发现很多数据补丁日志。尽管日志记录还不完善并且由于底层 PERL 库的性质而缺少一些东西，但在以下方面有很多很好的信息：
$ORACLE_BASE/cfgtoollogs/sqlpatch
因此，第一个重要部分是日志不在您的实际$ORACLE_HOME中。
你会在这个目录中找到什么？首先，您可能想知道日志的命名模式。它在名称中包含进程 ID，而不是容器名称或 ID。因此，导航有点困难。
但是有哪些类型的日志？我从MOS 注意：2680521.1 – Datapatch 用户指南中窃取了这个，因为它列出了各种日志：
| sqlpatch_invocation.log | 数据补丁完成的处理的详细日志 |
| sqlpatch_debug.log | 使用 –debug ，包含对故障排除有用的附加信息 |
| 引导程序*.sql | 由 datapatch 创建的脚本，用于在数据库中运行引导处理。 |
| 引导程序*.log | 在数据库中运行 bootstrap*.sql 脚本的日志文件（每个容器）。 |
| 安装*.sql | 由 datapatch 创建的脚本，用于运行补丁的应用和/或回滚脚本。对于 CDB，此脚本被传递给 catcon.pl 以在每个容器中运行。 |
| sqlpatch_catcon_*.log | catcon 在处理每个容器的 install<n> 脚本时创建的日志文件。（为 $ORACLE_BASE/cfgtoollogs/sqlpatch/patch_id 目录中的每个补丁 ID 捕获单独的应用/回滚日志）。 |
| sqlpatch_catcon__catcon_<action>.sql | 由 catcon 生成的脚本，用于在 CDB 的每个容器中执行特定操作。 |
| sqlpatch_catcon__catcon_<PID>.lst | catcon 启动日志文件；标识 catcon 日志文件位置 |
因此，“调用”日志通常是我想要分析修补运行时开始的地方。
我们现在错过的但有一个增强功能开放的是patch_summary.log，因为我们有它用于升级，乍一看向您展示了一个概述。
如果你想看看这些日志可以做什么，什么可以读取，什么不能，你可以阅读这篇博文：
- 当容器中有不同的组件时，datapatch 会做什么？
现在在我的环境中看起来如何？首先有一个与补丁号对齐的日志部分，例如：
├── 33515361 │ └── 24589353 │ ├── 33515361_apply_CDB2_CDBROOT_2022Jan19_21_47_29.log │ ├── 33515361_apply_CDB2_PDBSEED_2022Jan19_21_47_54.log │ ├── 33515361_apply_UP19_2022Jan19_23_17_14.log │ ├── 33515361_ru_apply_CDB2_CDBROOT_2022Jan19_21_47_28.log │ ├── 33515361_ru_apply_CDB2_PDBSEED_2022Jan19_21_47_53.log │ └── 33515361_ru_apply_UP19_2022Jan19_23_17_13.log
这是特定补丁的信息。您会看到它不仅应用于我的CDB2，还应用于另一个数据库UP19。
还有另一棵包含sqlpatch信息的树，包括sqlpatch_invocation.log：
├── sqlpatch_29286_2022_01_19_21_46_51 │ ├── bootstrap1_CDB2_CDBROOT.log │ ├── bootstrap1_CDB2_PDBSEED.log │ ├── bootstrap1.sql │ ├── install1.sql │ ├── sqlpatch_autorecomp_CDBROOT.log │ ├── sqlpatch_autorecomp_PDBSEED.log │ ├── sqlpatch_catcon_0.log │ ├── sqlpatch_catcon__catcon_29286.lst │ ├── sqlpatch_debug.log │ ├── sqlpatch_invocation.log │ ├── sqlpatch_progress.json │ └── sqlpatch_summary.json
现在要非常注意，由于命名，根目录的顺序很糟糕——更重要的是，你会发现所有的补丁都在这个目录中使用这个 $ORACLE_BASE 为你的所有家庭运行。
当我从 MOS 下载一个 3GB 的 zip 文件以查找特定数据库的问题时，这有时会成为一个很好的练习。特别是对于许多容器/PDB，它非常有趣。
如何加快数据补丁 - 规则 1？
现在我写了很多关于数据补丁的东西——但你可能会错过如何加速它的信息。
当然有很多东西要写和讨论——我不希望这篇博文变得太长，特别是因为很难找到正确的主题。
尽管如此，仍需要告知一条一般规则，尤其是对于多租户环境。
规则 1
如果您想使用 datapatch 加快修补速度，请事先重新编译。
您将特别感受到并看到大型多租户环境中的差异。确保您的 PDB 全部打开，然后调用重新编译：
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -e -b utlrp -d $ORACLE_HOME/rdbms/admin utlrp.sql
我们如何继续？
我希望你在这一点上不会太失望。只是一个小小的建议，但你们中的许多人现在肯定会说这并不能解决您当前的问题。但我想先给出一个广泛的概述，然后再深入挖掘并逐步进行。以下博客文章将更短，但也涵盖了我们似乎越来越多的一个领域。
所以请继续关注
原文标题：How to speed up datapatch – and much more information
原文作者：Mike.Dietrich
原文地址：https://mikedietrichde.com/2022/05/30/how-to-speed-up-datapatch-and-much-more-information/
