OPatchAuto在19c RAC中报冲突并回滚的根本原因是执行逻辑与环境状态不匹配：它试图在数据库/CRS仍运行时修改活跃二进制文件，触发CheckActiveFilesAndExecutables预检失败（OPATCHAUTO-68061），本质是活锁检测被触发，而非补丁间版本冲突。
OPatchAuto 在 19c RAC 中报冲突并回滚，根本原因不是补丁本身冲突，而是工具执行逻辑与环境状态不匹配——它试图在数据库/CRS 仍运行时强行修改活跃二进制文件，触发了 CheckActiveFilesAndExecutables 预检失败。
OPATCHAUTO-68061 回滚本质是“活锁检测”被触发
当你看到 OPATCHAUTO-68061: The orchestration engine failed 并伴随 Prerequisite check "CheckActiveFilesAndExecutables" failed，说明 opatchauto 发现当前 $ORACLE_HOME 下有进程正在使用待更新的库文件（如 libclntsh.so.19.1、libsqlplus.so），它不会冒险覆盖，直接中止并回滚已做操作。
- 这不是补丁之间版本冲突，而是运行时资源占用冲突
- 常见于：TFA 进程未停、监听器未关闭、SQL*Plus 或其他客户端连接未断开、甚至 crsctl status 命令残留子进程
- 节点1成功、节点2失败，往往是因为节点2上残留了节点1打补丁时遗留的连接或监控进程
为什么 opatchauto 不像 opatch apply 那样提示“请先停库”
opatchauto 设计为“自动协调”，但它只按预设剧本行动——它会尝试调用 srvctl stop database 或 crsctl stop crs，但这些命令可能因权限、OCR 状态、资源依赖失败而静默跳过；一旦没真正停掉实例，后续检查必然失败。
- 必须人工确认：
ps -ef | grep pmon和ps -ef | grep asm_pmon返回为空 -
crsctl check crs应返回 “CRS-4638: Oracle High Availability Services is online” 但所有资源状态需为OFFLINE（非ONLINE） - 尤其注意 TFA（Trace File Analyzer）：即使 CRS 停了，
tfa进程可能仍在后台采集日志，需执行/u01/app/19.0.0/grid/tfa/bin/tfactl stop
GI 和 DB 补丁混用 opatchauto 的权限陷阱
误用 grid 用户的 opatchauto 打 DB 补丁，或反过来，会导致路径解析错误、OCM 文件读取失败、甚至静默跳过关键校验步骤，最终在二进制替换阶段才暴露冲突。
- GI 补丁必须用
grid用户 +$GRID_HOME/OPatch/opatchauto，且-oh指向$GRID_HOME - DB 补丁必须用
oracle用户 +$ORACLE_HOME/OPatch/opatchauto，且-oh明确指向$ORACLE_HOME - 绝对不要在 root 下用
su - grid后再执行——环境变量（如ORACLE_HOME、PATH）可能未正确继承，导致opatchauto错误识别目标 home - 每次执行前，手动验证：
echo $ORACLE_HOME和which opatchauto必须严格对应
RU 补丁误走 opatchauto 路径引发的伪冲突
对 RU 补丁（如 p37960098_190000_Linux-x86-64）强行使用 opatchauto apply，会先通过预检（因为没涉及活跃文件），但在 SQL patch 阶段因无法触发 datapatch 而卡住，最终超时回滚——日志里可能不显示明确冲突，但 registry$sqlpatch 状态始终为 LOADING 或 ERROR。
- RU 补丁根本不支持
opatchauto，报OPATCHAUTO-72033是正常行为，不是配置问题 - 若跳过该错误继续强制执行，后续
datapatch -verbose可能因节点间字典不一致而失败，表现为 SQL 脚本反复重试、锁等待、甚至ORA-01031: insufficient privileges（因datapatch尝试以不同用户身份连接） - 真正需要检查的不是“补丁是否冲突”，而是 README 中 “Applicable to” 是否写明
RAC Rolling和opatchauto—— RU 补丁的 README 永远不会写这个
最易被忽略的一点：opatchauto 的“滚动”能力完全依赖 CRS 资源定义的完整性。如果某个数据库资源的 START_DEPENDENCIES 缺失 ASM 实例依赖，或监听器资源配置异常，opatchauto 在尝试停库时会失败却不报错，直接进入文件检查阶段，然后因文件被占用而回滚——此时查 CRS 日志比查 OPatch 日志更有效。
