Datapatch:数据库 12c 补丁后期 SQL 自动化 (文档 ID 2101974.1)
Posted on 2025-01-06 17:42 dclogs 阅读(9) 评论(0) 编辑 收藏 举报转自:https://www.cnblogs.com/erwadba/articles/8968834.html
文档内容
适用于:
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:
% datapatch
2) 关闭和重新打开受影响的 PDB
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 中的改变
杂项问题
- Catbundle 整合:现在假定 Datapatch 在安装 bundles/PSU 时拥有 catbundle 的角色。这个改变导致 catbundle.sql 被弃用,并且补丁注册只被维护在 registry$sqlpatch中。安装 PSU 不再更新 registry$history 表了。补丁安装的状态现在完全被维护在 registry$sqlpatch 中。
- 对补丁 UID 的支持:Datapatch 现在使用 patch-ID 和 patch-UID 来唯一的确定一个补丁。由于这项改变,datapatch 现在区分同一个补丁的不同版本。这使得 datapatch 可以正确的处理重新发行的补丁。
- 对 –force –rollback all 的支持: Datapatch 现在可以使用 –force 选项来从一个指定的 container DB 中回滚所有的补丁。这对于 container DB 的拔插是有用的。
- 整合进升级/降级脚本。
- 改善对于 PLS 错误和警告的检查。
先决条件检查
在 12.1.0.2 中,Datapatch 现在对于一些条件有先决条件检查。由于如下的原因和潜在的问题,这些先决条件检查会阻止补丁安装
- Upgrade 模式检查:
如果一个补丁要求以 Upgrade 模式启动数据库,datapatch 强制检查这个先决条件。要克服这个错误,DB/PDB 需要以 Upgrade/Migrate 模式重启,来完成补丁安装。请注意当一些补丁安装同时等待的时候,任何一个补丁要求以Upgrade 模式启动都会导致 datapatch的Upgrade 模式检查失败。数据库以Upgrade 模式启动并不会影响其它不需要使用Upgrade 模式启动的补丁的应用。对于不要求 Upgrade 模式的补丁,可以使用 –apply bug # 选项来调用 datapatch 安装。
- 检查安装/回滚脚本的存在:
Datapatch 现在为所有在未完成的补丁安装/回滚确认安装/回滚脚本的存在。如果文件不可用,datapatch 会失败并报出一个先决条件检查错误。对于异地回滚,请复制所有 sqlpatch 文件到 $OH 来完成这个检查,并允许回滚执行。
- 与 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
- 与数据库的连接:
Datapatch 使用先决条件检查来确保与数据库的连接。
- 先决条件检查确保我们可以在 cfgtoollogs 目录下创建目录。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库