opatchauto 必须带 -nonrolling 参数，因其默认跨节点并行打补丁，违反RAC滚动“单节点串行隔离变更”本质；-nonrolling 是人工控制滚动节奏的开关，确保仅操作当前节点，避免CRS资源冲突。
能实现零停机，但前提是每个环节都按 rac 滚动语义严格执行——漏掉 opatchauto 的 -nonrolling、-oh 或 -ocmrf，就不是滚动，而是故障前奏。
为什么 opatchauto 必须带 -nonrolling 参数
opatchauto apply 默认尝试跨节点并行打补丁，这在 RAC 中直接违反滚动前提。RAC 滚动的本质是「单节点串行隔离变更」，-nonrolling 并非关闭滚动，而是告诉工具：本次只处理当前节点，不调度其他节点——这是人工控制滚动节奏的开关。
- 不加
-nonrolling：opatchauto 会尝试同时操作两个节点，触发 CRS 资源冲突，报错CRS-4000: Command Stop failed或卡死在locking OH - 加了但没指定
-oh：命令默认作用于当前$ORACLE_HOME，若以grid用户执行却未显式写-oh /u01/app/12.2.0/grid，可能误打到 DB HOME，导致 GI 和 DB 版本错配 - 同一补丁包对 GI 和 DB 需分别执行两次命令：一次用
-oh指向GRID_HOME，另一次指向ORACLE_HOME，不能合并
ocm.rsp 文件为什么必须提前生成且复用
opatchauto 内部调用 emocmrsp 收集集群配置，若未提供 -ocmrf，它会在第一个节点打补丁中途弹出交互式提示（如要求输入 email、proxy），此时节点 1 的 GI 已部分更新、节点 2 仍运行旧版本，集群进入半升级状态，crsctl check cluster -all 可能返回 inconsistent，且无法回退。
- 生成命令（任一节点执行一次即可）：
$ORACLE_HOME/OPatch/ocm/bin/emocmrsp -output /tmp/ocm.rsp - 后续所有
opatchauto apply命令都必须带上：-ocmrf /tmp/ocm.rsp - 文件权限需为
grid:oinstall（GI 补丁）或oracle:oinstall（DB 补丁），否则 opatchauto 报OCM configuration file is not readable
补丁应用后数据库实例没自动拉起？检查 srvctl modify database
RAC 实例由 CRS 自动管理，补丁完成后不会自动切换到新 ORACLE_HOME 下运行——除非你提前用 srvctl 显式绑定。如果发现 ps -ef | grep pmon 显示实例仍在旧路径下启动，说明这步被跳过了。
- 确认当前 HOME：
srvctl config database -d <db_name></db_name>输出中的Oracle home字段 - 若指向旧路径，执行：
srvctl modify database -d <db_name> -o <new_oracle_home></new_oracle_home></db_name> - 修改后无需重启实例，下次 CRS 重启该资源（如
crsctl stop res ora.<db_name>.db -init</db_name>后再 start）就会从新 HOME 拉起 - 注意：此操作仅影响数据库资源，ASM 实例由
srvctl modify asm管理，Flex ASM 还需额外检查srvctl status asm -detail
滚动失败最隐蔽的信号：不是报错，而是资源状态假 ONLINE
真正让业务感知中断的，往往不是命令失败，而是底层资源看似正常、实则不可用。比如：
-
crsctl stat res -t | grep ACFS显示ONLINE，但df -h看不到挂载点 →acfsload驱动未随 GI 补丁同步更新，需手动运行acfsload start -
crsctl check cluster -all全绿，但ALTER DISKGROUP ... REBALANCE卡住 → ASM 实例依赖的GRID_HOME补丁未完成，而业务恰好在做磁盘组重平衡 - 启用了 Flex ASM，某节点补丁后 ASM 实例异常终止，
srvctl status asm -node <node></node>显示OFFLINE，但客户端连接不会自动漂移 → 必须手工执行srvctl relocate asm -node <node></node>
这些情况都不会导致 opatchauto 报错退出，但业务侧会出现 IO 延迟、连接超时等现象——滚动升级里最耗时间的，其实是验证这些「看起来没问题」的状态。
