OPatchAuto在Oracle 19c RAC中回滚失败的根本原因不是回滚逻辑错误，而是回滚前预检再次失败：CheckActiveFilesAndExecutables检测到残留进程（如tfa、监听器、sqlplus会话）仍在占用二进制文件，导致无法安全还原；同时用户与HOME不匹配、环境变量污染或Inventory权限不足也会触发静默跳过或报错。
OPatchAuto 在 Oracle 19c RAC 中执行补丁回滚失败，根本原因不是“回滚逻辑出错”，而是回滚动作本身依赖于一个干净、静止的运行时环境——而这个环境在补丁失败后往往已被破坏。你看到的 OPATCHAUTO-68061 或 PREREQ_CHECK_FAILED 错误，通常不是回滚命令写错了，而是回滚前的预检再次失败。
回滚失败时 opatchauto rollback 报 CheckActiveFilesAndExecutables 失败
这是最典型的卡点：补丁安装中途失败并触发自动回滚，但回滚阶段仍检测到活跃进程正在使用待还原的二进制文件（如 libclntsh.so.19.1、oracle 可执行体），于是拒绝继续，陷入“想退退不了”的状态。
- 这说明节点上仍有残留进程未释放对 $ORACLE_HOME 的占用，常见来源包括：
-
tfa进程仍在后台采集日志（即使 CRS 已停） - 监听器（
lsnrctl）未真正关闭，或监听端口被其他进程绑定 -
sqlplus / as sysdba会话未退出，尤其连接了 ASM 实例（+ASM1） -
crsctl check crs返回 “online”，但部分资源（如ora.qosmserver）实际卡在 STARTING 状态，导致opatchauto误判环境可用
-
- 不要直接杀
pmon或asm_pmon进程——这可能触发实例崩溃或 OCR 写入异常 - 正确做法是逐层确认真实状态：
- 执行
ps -ef | grep pmon | grep -v grep和ps -ef | grep asm_pmon | grep -v grep，输出必须为空 - 运行
crsctl stat res -t | grep ONLINE，确认无数据库、监听器、VIP 资源处于 ONLINE - 检查
/u01/app/19.0.0/grid/tfa/bin/tfactl status，若显示 running，先执行tfactl stop GI（GI 补丁）或tfactl stop DB（DB 补丁）
- 执行
opatchauto rollback 静默跳过某节点或报权限错误
这基本可锁定为用户与 ORACLE_HOME / GRID_HOME 匹配错误，或环境变量污染：
- GI 补丁回滚必须用
grid用户，且ORACLE_HOME必须未设置（或明确 unset），否则opatchauto会误读路径，尝试操作 DB HOME 下的文件 - DB 补丁回滚必须用
oracle用户，并确保ORACLE_HOME指向正确的数据库主目录（不能是 GRID_HOME） - 切忌用
su - grid后再执行——某些 shell 会继承父 shell 的ORACLE_HOME，导致opatchauto自动识别错目标；应改用sudo -u grid bash -c "cd $GRID_HOME/OPatch; ./opatchauto rollback ..." - 若提示
OCM response file not found或oui-patch.xml permission denied，说明回滚需读写 Oracle Inventory 文件，检查/oracle/app/oraInventory/ContentsXML/oui-patch.xml是否存在且grid或oracle用户有写权限（chmod 664即可）
回滚失败后无法启动数据库，只能强制清理
当 opatchauto rollback 完全不可用，且节点已处于半损坏状态（如 CRS 启动失败、ASM 实例无法 MOUNT），需人工介入还原关键文件：
- 先确认补丁 ID：
opatch lsinventory -detail查看最后成功应用的补丁号（如34567890），再定位其备份目录：$ORACLE_HOME/.patch<em>storage/34567890</em>*_backup - 进入该目录，找到
backup_files.txt，里面记录了所有被替换的原始文件路径（如$ORACLE_HOME/lib/libclntsh.so.19.1.orig） - 手动还原（仅限紧急）：
cp $ORACLE_HOME/lib/libclntsh.so.19.1.orig $ORACLE_HOME/lib/libclntsh.so.19.1chmod 755 $ORACLE_HOME/lib/libclntsh.so.19.1- 重复此操作，覆盖所有
.orig文件（注意别漏掉bin/oracle、rdbms/lib/env_rdbms.mk等核心项）
- 还原后清空 OPatch 缓存：
rm -rf $ORACLE_HOME/.patch_storage/*，再试opatch lsinventory确认补丁列表已清空
最关键的一点：补丁失败后的“紧急处理”不是比谁命令敲得快，而是比谁对当前节点真实状态判断得准。很多所谓“回滚失败”，其实是还没真正停掉 tfa 或没发现 qosmserver 卡在启动中——这些细节不会报在错误第一行，但会决定整个恢复路径是否成立。
