OPATCHAUTO-68061 是活锁检测触发的回滚，非补丁版本冲突；根本原因是 opatchauto 在数据库/CRS 运行时检测到 $ORACLE_HOME 下有进程正使用待更新的共享库（如 libclntsh.so.19.1），为避免覆盖活跃二进制而强制中止并回滚。
OPatch冲突错误不是补丁之间打架，而是工具发现“文件正被使用”，立刻中止并回滚——它宁可失败，也不覆盖运行中的二进制。
OPATCHAUTO-68061 是活锁检测，不是版本冲突
看到 OPATCHAUTO-68061 和 Prerequisite check "CheckActiveFilesAndExecutables" failed，说明 opatchauto 扫描到 $ORACLE_HOME 下有进程正在加载待更新的共享库（比如 libclntsh.so.19.1、libsqlplus.so），直接拒绝继续。这不是补丁包之间不兼容，是运行时资源被占用了。
常见诱因包括：
- TFA 进程仍在后台采集日志（即使
crsctl check crs显示正常，/u01/app/19.0.0/grid/tfa/bin/tfactl stop GI也得手动执行） - 监听器没停：
lsnrctl stop后还要确认ps -ef | grep tnslsnr无残留 - SQL*Plus 或其他客户端连接未断开，尤其是用
sqlplus / as sysdba连着没退出 - 节点1打完补丁后，节点2上还留着节点1触发的监控子进程（
crsctl status命令本身可能遗留 shell 子进程）
opatchauto 不提示“请先停库”，是因为它假装能自动协调
opatchauto 设计上会尝试调用 srvctl stop database 或 crsctl stop crs，但它不会校验这些命令是否真成功了。权限不足、OCR 状态异常、资源依赖卡住，都可能导致命令静默失败或部分执行——而 opatchauto 接着就往下走，直到预检阶段才爆 CheckActiveFilesAndExecutables 错误。
必须人工确认：
-
ps -ef | grep pmon和ps -ef | grep asm_pmon返回为空（不能只看crsctl check crs） -
crsctl stat res -t中所有数据库、实例、监听器资源状态为OFFLINE（不是ONLINE） - 哪怕 CRS 已停，也要单独停 TFA：
tfacl stop GI和tfacl stop DB
用户/路径错配：grid 用户打 DB 补丁，或 -oh 指向错误
GI 补丁和 DB 补丁必须严格区分执行主体和目标路径：
- GI 补丁：必须用
grid用户 +$GRID_HOME/OPatch/opatchauto+-oh $GRID_HOME - DB 补丁：必须用
oracle用户 +$ORACLE_HOME/OPatch/opatchauto+-oh $ORACLE_HOME - 绝对不要用
su - grid后再执行——ORACLE_HOME、PATH等环境变量极大概率未继承，导致opatchauto错误识别目标 home - 每次执行前务必验证：
echo $ORACLE_HOME和which opatchauto，确保指向正确位置
LANG=C 缺失引发 “unable to get oracle owner” 类报错
Linux 系统若配置了中文 locale（如 LANG=zh_CN.UTF-8），opatchauto 内部解析用户属主信息时可能因多字节字符截断失败，报出类似 unable to get oracle owner 的错误，而非明确的权限提示。
解决方法很简单：
- 临时切语言：
export LANG=C - 再执行
opatchauto命令 - 无需改系统默认 locale，仅当前会话生效即可
真正麻烦的从来不是补丁本身，而是那些没显式报错却悄悄卡住的进程、没继承的环境变量、以及你以为它自动做了但其实没做的停库动作——这些点漏一个，opatchauto 就会在 CheckActiveFilesAndExecutables 那一步冷酷回滚。
