opatchauto在Oracle 19c RAC上不能用于RU补丁滚动更新，因其已从19c起被硬性弃用；RU必须通过opatch apply加datapatch手动分步执行，且RAC需逐节点操作并严格验证registry$sqlpatch状态。
opatchauto 在 Oracle 19c RAC 上**不能用于 RU（Release Update）补丁的滚动更新**——这是硬性限制，不是操作失误导致的失败。它只适用于 PSU、BP（Bundle Patch）或 GI-only 补丁，且必须严格匹配文档要求的补丁类型和 OPatch 版本。
为什么 opatchauto apply 会报 OPATCHAUTO-72033 错误
当你对 19c ru 补丁（如 p34130714_190000_linux-x86-64）执行 opatchauto apply 时，大概率遇到：
OPATCHAUTO-72033: This patch is not applicable for auto patching.
这不是权限或路径问题，而是 Oracle 从 19c 开始彻底移除了 opatchauto 对 RU 的支持逻辑。RU 补丁含字典变更、PDB-aware SQL 脚本、跨实例一致性校验等，opatchauto 无法触发 datapatch、无法协调所有节点统一重启时机，因此直接拒绝执行。
常见误判场景：
- 看到 Metalink 文档里写了 “opatchauto supported”，但没注意该文档适用版本是 12.2 或 18c —— 19c RU 明确排除
- 用
opatchauto成功打了 GI 补丁，就以为 DB 补丁也能套用同一命令 - 把 RU 补丁解压后直接传给
opatchauto apply，未检查 README 中 “Applicable to” 字段
哪些补丁还能用 opatchauto 滚动打
仅限以下两类，且必须满足全部条件：
-
PSU或BP类型补丁（非 RU/RUR），例如p31305209_112040_Linux-x86-64（虽然这是 11g 补丁，但逻辑一致） - 补丁 README 明确声明支持
opatchauto且标注 “RAC Rolling” - GI 和 DB 的
$ORACLE_HOME/OPatch均升级到补丁要求的最低版本（如 12.2.0.1.39） - 每个节点上，
grid用户和oracle用户各自的$ORACLE_HOME下都单独升级并验证过opatch version - 提前生成
ocm.rsp：运行$ORACLE_HOME/OPatch/ocm/bin/emocmrsp -output /tmp/ocm.rsp，后续命令必须带-ocmrf /tmp/ocm.rsp
典型可用命令（以 GI 补丁为例）：
/u01/app/19.0.0/grid/OPatch/opatchauto apply /soft/p34130714 -oh /u01/app/19.0.0/grid -nonrolling -ocmrf /tmp/ocm.rsp
注意：-nonrolling 不代表“不滚动”，而是告诉 opatchauto 本次只处理当前节点（滚动的第一步），缺它会导致跨节点并发失败。
RAC 环境下 opatchauto 最容易卡住的三个环节
opatchauto 在 19c RAC 上不是“一键到底”，中间有多个需人工确认或干预的断点：
-
节点切换卡在 “locking OH”：未对
$ORACLE_HOME/OPatch执行chown -R grid:oinstall（GI）或chown -R oracle:oinstall（DB），导致进程无权修改 inventory -
第二节点启动失败：第一节点打完后未手动验证
crsctl check cluster和srvctl status database，第二节点启动时发现集群状态异常而中止 -
补丁冲突未预检：未提前在各节点运行
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /soft/p34130714，导致opatchauto在 apply 阶段才发现冲突并回滚，已停的服务无法自动恢复
建议每步完成后，立刻检查：
crsctl query crs activeversion（确认 GI 版本一致）
$ORACLE_HOME/OPatch/opatch lsinventory -detail（确认补丁已登记）
tail -n 20 /u01/app/19.0.0/grid/cfgtoollogs/opatchauto/opatchauto*.log（看最后几行是否含 “Patch application completed successfully”）
真正需要滚动更新 RU 时该怎么办
别硬套 opatchauto。19c RU 的滚动本质是“伪滚动”：所有节点必须最终运行相同 RU 版本，且 datapatch 必须在所有实例启动后立即执行。实际可行路径只有两条：
-
分节点顺序停启 + 手动 opatch apply + datapatch：节点1停实例 →
opatch apply -local→ 启实例 →datapatch -verbose→ 节点2重复。这是最稳妥、被 Oracle Support 认可的方式 -
利用安装时 applyRU 机制：仅适用于全新部署或重装 DB HOME，命令如
./runInstaller -applyRU /path/to/ru，OPatch 版本必须提前升级好，否则 installer 直接退出
关键提醒：无论选哪种，registry$sqlpatch 中每条记录的 status 必须全为 SUCCESS，且 action_time 是你刚打的 RU 时间戳——这才是 RU 生效的唯一可信依据，opatch lsinventory 只显示文件层安装，不反映数据库字典状态。
