Datapatch：数据库 12c 补丁后期 SQL 自动化 (文档 ID 2101974.1)

适用于:

Oracle Database - Enterprise Edition - 版本 12.1.0.1 和更高版本
Oracle Database - Personal Edition - 版本 12.1.0.1 和更高版本
Oracle Database - Standard Edition - 版本 12.1.0.1 和更高版本
本文档所含信息适用于所有平台

用途

 解释数据库 12c 补丁后期 SQL 自动化。

适用范围

数据库版本 12c 将补丁的安装自动化扩展到了需要安装后执行 SQL 步骤的补丁。
在 12c 之前，这样的补丁要求在数据库重启完成后，手动执行安装后期 SQL 步骤。
Datapatch 是一个新的工具，它可以自动执行 RDBMS 补丁的安装后期 SQL 步骤。
Datapatch 放置在 opatch 目录中，即，$ORACLE_HOME/OPatch 目录。（在 Windows 平台是 %ORACLE_HOME%\OPatch）

在安装补丁并重启数据库后，可以执行 Datapatch 来完成安装后期 SQL 步骤。
对于没有安装后期 SQL 步骤的补丁，执行 Datapatch 不会有任何效果。 
对于需要在安装补丁后对数据库实例执行 SQL 步骤的补丁，datapatch 会自动探测到所有等待的动作（从一个已安装的补丁或者多个已安装的补丁），并且以适当的方式完成这些动作。

文档的其余部分会提供有关 datapatch 的进一步细节。
Enterprise Manager 和 OPatchAuto 通过在安装完补丁的二进制文件后自动的调用 datapatch，进一步实现了数据库补丁的自动化。


如下的部分描述了不同的打补丁工具如何的实现自动化流程。

详细信息

Enterprise Manager:

从 12.1 版本开始 Enterprise Manager 现在调用 datapatch 来完成对 12c 或之后版本的补丁后期动作。 
如上所述，datapatch 包含一个逻辑来确认是否有任何补丁后期 SQL 动作需要执行。

OPatchAuto :

在安装了二进制补丁和重启数据库的基础上，OPatchAuto 调用 datapatch 来完成补丁后期动作。
如前所述，datapatch 确定需要的补丁后期操作，并且自动完成它们。 
补丁后期动作包括应用，以及移除或者回滚对数据库的 SQL 改变。

OPatch :

结合使用 Datapatch 和 OPatch 是不可能的，因为 OPatch 是在数据库停机状态执行，而 datapatch 要求数据库必须处于打开状态，才能完成动作。
若在补丁说明中有要求，那么当使用 OPatch 来安装或者回滚补丁时，datapatch 必须被显式的调用。 
Datapatch 被设计成幂等的，可以为所有的补丁运行，并且，推荐在使用 OPatch 进行任何应用或回滚动作之后，运行 datapatch。（计算机术语中，幂等操作是指在使用相同的参数调用超过一次时，没有任何额外效果的操作）

Datapatch :

Datapatch 是用来为 RDBMS 补丁完成补丁后期动作的工具。

仅限 Windows： 在 Windows 平台脚本名字是 datapatch.bat。

仅限 RAC: 在 RAC 环境，在二进制补丁安装到所有节点之后，仅需在其中一个节点运行 Datapatch 来完成 PSU 的安装后期 SQL 部署。Datapatch 不需要在所有节点运行。

Datapatch 通过匹配一个内部的知识库与补丁清单来确定必须的应用/回滚动作。
Datapatch 应在数据库安装补丁并重启后被调用。
Enterprise Manager 和 OPatchAuto 在应用每一个补丁中自动调用 datapatch 。
如果使用 OPatch 来安装 RDBMS 补丁，那么必须显式的调用 datapatch 来完成任何数据库重启后的补丁动作。
Datapatch 会自动的确定需要被安装的补丁组和需要回滚的补丁组。

Datapatch 确保了在开始对数据库进行任何补丁后期 SQL 动作之前，这个补丁在所有的 RAC 实例上已安装或者回滚。在 Oracle 多租户环境，datapatch 会将补丁安装到 root 和任何一个打开状态的可拔插数据库。
为了将补丁安装到所有的可拔插数据库，应该确保在调用 datapatch 之前，所有的可拔插数据库都被打开。
如果在一个多租户环境中，一个没有安装补丁的可拔插数据库被打开了，那么调用 datapatch 会完成在等待的补丁动作。

Datapatch usage :

所有的参数都是可选的，如果不提供任何参数，datapatch 会自动确定需要运行哪些脚本，来完成所有包含后期 SQL 操作的补丁的安装。

可选参数：

-db <db name>
使用指定数据库取代 $ORACLE_SID

-apply <patch1,patch2,...,patchn>
只对列表中指定的补丁进行安装操作

-rollback <patch1,patch2,...,patchn>
只对列表中指定的补丁进行回滚操作

-force
即使 SQL 注册信息不要求，也运行安装/回滚脚本

-prereq
只运行先决条件检查，不实际运行任何脚本

-oh <oracle_home value>
使用指定的目录来确定已安装的补丁

-verbose
输出额外的诊断信息

-help
输出帮助信息并退出

-version
输出版本信息并退出

在多租户环境中的 Datapatch：

当在一个多租户环境中运行 Datapatch 来调用任何 SQL 动作时，datapatch 会基于等待的动作，只应用改变到 ROOT，SEED 和任何打开状态的 PDB。 对任何当前不处于打开状态的 PDB，SQL PATCH 不会被应用。当这样一个 PDB 再次打开时，它会以 restricted 模式打开，因为这个 PDB 和 ROOT 的补丁级别是不一致的。  

在 12.1.0.1 上调用 DBMS_PDB.CHECK_PLUG_COMPATIBILITY。PDB xml 文件会返回两条违例。这是期望的行为。
  SQL Patch              ERROR
  
SQL patch bug # mismatch: Installed in the PDB but not in the CDB.   Install the SQL patch in the PDB or the CDB

可以通过再次运行 datapatch，关闭和重新打开受影响的 PDB 来清除这个错误。

1)    调用 datapatch:

% cd $ORACLE_HOME/OPatch
% datapatch

2)    关闭和重新打开受影响的 PDB

Connect as SYS
alter pluggable database <PDB Name> close instances =all;
alter pluggable database <PDB Name> open read write instances =all;

3)    再次检查违例（通过查询 cdb$root 中的 pdb_plug_in_violations），应该不存在了，并且可拔插数据库应该被打开到正常模式。

数据库版本 12.1.0.2 中的改变

杂项问题

1. Catbundle 整合：现在假定 Datapatch 在安装 bundles/PSU 时拥有 catbundle 的角色。这个改变导致 catbundle.sql 被弃用，并且补丁注册只被维护在 registry$sqlpatch中。安装 PSU 不再更新 registry$history 表了。补丁安装的状态现在完全被维护在 registry$sqlpatch 中。
2. 对补丁 UID 的支持：Datapatch 现在使用 patch-ID 和 patch-UID 来唯一的确定一个补丁。由于这项改变，datapatch 现在区分同一个补丁的不同版本。这使得 datapatch 可以正确的处理重新发行的补丁。
3. 对 –force –rollback all 的支持: Datapatch 现在可以使用 –force 选项来从一个指定的 container DB 中回滚所有的补丁。这对于 container DB 的拔插是有用的。
4. 整合进升级/降级脚本。
5. 改善对于 PLS 错误和警告的检查。

先决条件检查

在 12.1.0.2 中，Datapatch 现在对于一些条件有先决条件检查。由于如下的原因和潜在的问题，这些先决条件检查会阻止补丁安装

1. Upgrade 模式检查：
   
   如果一个补丁要求以 Upgrade 模式启动数据库，datapatch 强制检查这个先决条件。要克服这个错误，DB/PDB 需要以 Upgrade/Migrate 模式重启，来完成补丁安装。请注意当一些补丁安装同时等待的时候，任何一个补丁要求以Upgrade 模式启动都会导致 datapatch的Upgrade 模式检查失败。数据库以Upgrade 模式启动并不会影响其它不需要使用Upgrade 模式启动的补丁的应用。对于不要求 Upgrade 模式的补丁，可以使用 –apply bug # 选项来调用 datapatch 安装。
    
2. 检查安装/回滚脚本的存在：
   
   Datapatch 现在为所有在未完成的补丁安装/回滚确认安装/回滚脚本的存在。如果文件不可用，datapatch 会失败并报出一个先决条件检查错误。对于异地回滚，请复制所有 sqlpatch 文件到 $OH 来完成这个检查，并允许回滚执行。
    
3. 与 Queryable Inventory 的连接：
    
   如果由于某些原因，Queryable Inventory 返回一个错误状态，Datapatch 会标示一个 Queryable Inventory 错误。可以通过调用“select dbms_qopatch.get_pending_activity from dual”和注意其错误消息，来展示进一步的细节。有关解决 Queryable Inventory 问题的更多细节可以在如下文档找到：
   NOTE:1530108.1 - Oracle Database 12.1 : FAQ on Queryable Patch Inventory
    
4. 与数据库的连接：

   Datapatch 使用先决条件检查来确保与数据库的连接。

5. 先决条件检查确保我们可以在 cfgtoollogs 目录下创建目录。