opatchauto 是 Oracle RAC 滚动升级 PSU 的核心工具，必须升级 OPatch 至指定版本、分步执行 GI 和 DB 补丁、提供 ocm.rsp 响应文件，并人工确认节点切换。
opatchauto 是 Oracle RAC 滚动升级 PSU 的核心工具，它能自动协调节点启停、补丁顺序和组件依赖。直接用 opatch apply 在 RAC 上打补丁会失败或导致集群不稳定——这不是权限问题，而是架构限制。
必须先升级 OPatch 到补丁要求的最低版本
几乎所有 11g/12c/19c 的 psu 都明确要求 opatch 版本 ≥ 某个值（比如 11.2.0.3.21 或 12.2.0.1.19），低于该版本时 opatchauto 会直接报错退出，不提示具体原因。
- 每个节点上，
grid用户和oracle用户各自的$ORACLE_HOME下都必须单独升级OPatch - 升级前务必
mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.bak备份，避免解压覆盖出错后无法回退 -
chown -R grid:oinstall $ORACLE_HOME/OPatch和chown -R oracle:oinstall $ORACLE_HOME/OPatch必须执行，否则opatchauto运行时会因权限不足卡在“locking OH”阶段 - 验证方式统一为：
$ORACLE_HOME/OPatch/opatch version，不能只看which opatch
opatchauto apply 必须带 -oh 和 -nonrolling 参数分步执行
所谓“滚动”，是指 GI 补丁和 DB 补丁不能混在同一命令中自动调度；Oracle 强制要求先打 GI（grid home），再打 DB（oracle home），且每个 home 必须指定 -oh，否则默认作用于当前 $ORACLE_HOME，极易误操作。
- 打 GI 补丁（两节点滚动）：
/u01/app/11.2.0/grid/OPatch/opatchauto apply /soft/p31305209_112040_Linux-x86-64 -oh /u01/app/11.2.0/grid -nonrolling - 打 DB 补丁（两节点滚动）：
/u01/app/oracle/product/11.2.0/db_1/OPatch/opatchauto apply /soft/p31305209_112040_Linux-x86-64 -oh /u01/app/oracle/product/11.2.0/db_1 -nonrolling -
-nonrolling不代表“非滚动”，而是指本次命令只处理单个节点（即进入滚动模式的第一步），省略它会导致opatchauto尝试跨节点并行，失败率极高 - 补丁目录（如
/soft/p31305209_112040_Linux-x86-64）必须是已解压后的顶层目录，不能是 zip 包路径
生成并复用 ocm.rsp 响应文件，避免交互中断
opatchauto 在执行过程中会调用 emocmrsp 生成配置响应，若未提前提供，会在节点 1 安装中途弹出交互式提示，导致整个滚动流程卡死——而此时节点 1 的 GI 已部分更新、节点 2 仍运行旧版本，集群处于不一致状态。
- 只需在任意节点用
grid用户执行一次：$ORACLE_HOME/OPatch/ocm/bin/emocmrsp -output /tmp/ocm.rsp - 后续所有
opatchauto命令都必须加上-ocmrf /tmp/ocm.rsp，包括 GI 和 DB 阶段 - 该文件无敏感信息，可安全复用，无需每节点重生成
- 注意路径权限：
chmod 775 /tmp/ocm.rsp，否则oracle用户执行 DB 补丁时会因读取失败退出
真正容易被忽略的是：滚动升级不是“自动完成”，而是“自动分步 + 手动确认节点切换”。opatchauto 只负责单节点内流程，节点间顺序、服务启停时机、CRS 状态检查仍需人工介入判断——尤其当 crsctl check cluster -all 在某节点返回异常时，强行继续会引发 OCR 损坏。
