如何应用Oracle补丁_OPatch工具与PSU/RU补丁安装流程-Oracle-PHP中文网

opatch版本不匹配是补丁失败主因，需升级至mos要求的最低版本并更新path；ru与psu不可混装，须确认基线一致；rac环境须全节点校验、同步执行root.sh并验证状态。

opatch 版本不匹配导致 `opatch lsinventory` 报错

oracle 补丁安装失败，十有八九卡在第一步：连 opatch lsinventory 都跑不起来。根本原因常是 opatch 版本太老，不支持当前数据库版本或补丁格式（比如 19c 的 ru 补丁要求 opatch 至少 12.2.0.1.32）。旧版 opatch 解析不了新补丁元数据，直接抛出 invalid inventory location 或静默失败。

先确认 Oracle Home 路径，进到 $ORACLE_HOME/OPatch 下执行 opatch version
去 MOS 文档 Document ID 274526.1 查对应数据库版本所需的最低 OPatch 版本，下载后解压覆盖原 $ORACLE_HOME/OPatch（不用卸载，直接覆盖）
覆盖后务必重设环境变量：export PATH=$ORACLE_HOME/OPatch:$PATH，否则系统可能仍调用旧版
别跳过 opatch lsinventory -detail —— 它能暴露 Oracle Inventory 是否损坏，若报 Inventory load failed，得用 runInstaller -ignoreSysPrereqs -force -silent -attachHome 修复

PSU 和 RU 补丁不能混装，`opatch apply` 会拒绝

12.2 开始，Oracle 彻底区分 PSU（Patch Set Update）和 RU（Release Update），两者补丁包结构、冲突检测逻辑、回滚方式都不同。强行把 RU 补丁丢进原为 PSU 构建的环境里运行 opatch apply，会立刻报 Conflicts with installed patches 或更直白的 This patch is not applicable for this environment。

查当前已装补丁类型：opatch lsinventory | grep -i "patch description"，看是否含 Release Update 字样
RU 补丁必须基于“干净”的 RU 基线安装；若当前是 PSU，得先升级到对应 RU（如从 19.10 PSU 升到 19.18 RU），不能跨基线打补丁
RU 补丁名形如 p35021191_190000_Linux-x86-64.zip，末尾数字是 RU 编号；PSU 名则是 p34567890_190000_Linux-x86-64.zip，无 RU 标识
升级 RU 时，opatch auto 会自动停库、打补丁、启库；但若用 opatch apply 手动打，必须自己停 sqlplus / as sysdba 中的实例，否则报 Database instance is running

`opatch auto` 失败后，别急着重试，先看 `$ORACLE_HOME/cfgtoollogs/opatchauto`

opatch auto 看似全自动，实则只是封装了 stop/start + opatch apply + datapatch 调用。一旦中间某步失败（比如 datapatch 执行 SQL 报错），它不会清理现场，直接退出。此时再跑一遍 opatch auto，大概率卡在同一个地方，甚至引发 inventory 锁死。

失败后第一件事：进 $ORACLE_HOME/cfgtoollogs/opatchauto，按时间戳找最新子目录，重点看 opatchauto.log 和 datapatch.log
常见陷阱是 datapatch 报 ORA-01031: insufficient privileges —— 这不是权限问题，而是数据库没 open（尤其 RAC 中单实例未启），需手动 sqlplus / as sysdba 后 startup
若 opatch auto 卡住不动，检查 ps -ef | grep opatch，可能残留后台进程锁住了 inventory，用 opatch lsinventory -detail 确认状态，必要时杀掉并删 $ORACLE_HOME/.patch_storage 下临时目录（谨慎！仅当明确无其他 opatch 运行时）
真要重试，先 opatch rollback -id <patch_id></patch_id> 回滚已部分应用的部分，再重新 opatch auto

RAC 环境下漏掉 `root.sh` 或节点间 OPatch 版本不一致

RAC 不是单机放大版。两个节点上 opatch 版本差一个小版本，或者打完补丁忘了在所有节点跑 root.sh，都会导致后续实例无法启动、CRS 资源异常，错误日志里反复出现 ORA-29516 或 CLSRSC-464。

打补丁前，先在所有节点执行 cluvfy comp patch -n all -o ocr -verbose，它会校验 OPatch 版本、GI 状态、OCR 可访问性
opatch auto 默认只在本地节点运行，RAC 必须加 -oh $ORACLE_HOME -ocmrf /tmp/ocm.rsp 并确保 ocm.rsp 在所有节点路径一致；否则补丁只装一半
补丁应用完成后，在每个节点单独执行 $ORACLE_HOME/root.sh（注意不是 GI 的 root.sh），它会同步 OCR 中的 patch 信息
最后验证：crsctl query crs activeversion 看 GI 版本，srvctl status database -d <db_name></db_name> 看所有实例是否 online，再进每个实例查 select * from dba_registry_sqlpatch