OPatch rollback失败主因是补丁元数据缺失或文件被占用；需先用lsinventory确认补丁存在，停进程并检查lsof，SQL变更须手动执行rollback脚本，多补丁回退须确保无依赖关系。
opatch rollback 命令执行失败：提示 OPatch failed with error code 73
这是最常见的回退失败，根本原因通常是补丁未被正确识别为“已应用”状态——opatch rollback 不是按时间或编号倒序撤销，而是严格依赖 $oracle_home/.patch_storage/ 下的元数据记录。如果该目录被清理过、或补丁曾用非 opatch 方式安装（比如手动拷文件），opatch 就找不到对应条目。
实操建议：
- 先运行
opatch lsinventory -detail，确认目标补丁的Patch ID和Applied on时间是否在输出中真实存在 - 若不在列表里，
rollback必然失败；此时不能硬试，需查安装日志$ORACLE_HOME/cfgtoollogs/opatch/*.log找原始apply记录 - 别直接删
.patch_storage目录——这等于让opatch“失忆”，后续所有补丁管理都会出问题
回退指定补丁但报错 Prerequisite check "CheckActiveFilesAndExecutables" failed
Oracle 在回退前会校验相关二进制文件是否正被使用（比如数据库实例、监听器、ASM 进程），只要有一个进程锁住了 libclntsh.so 或 oracle 可执行文件，检查就失败。
实操建议：
- 停掉所有 Oracle 相关进程：
sqlplus / as sysdba中执行shutdown immediate，再lsnrctl stop，最后确认ps -ef | grep -i "ora_\|tnslsnr"无残留 - Linux 下可用
lsof +D $ORACLE_HOME快速定位谁还在占用文件（注意需 root 权限） - 某些补丁涉及 OPatch 自身升级（如 12.2.0.1.24+），回退前要确保当前
opatch版本 ≥ 被回退补丁安装时的版本，否则校验直接跳过并报错
opatch rollback 后数据库无法启动：ORA-00704 / ORA-00604
这不是 opatch 的常规行为，而是说明该补丁包含 SQL 部分（如 catbundle.sql），而回退命令默认只处理二进制层，SQL 层变更必须手动逆向执行——opatch rollback 从不自动运行 rollback SQL。
实操建议：
- 查看补丁解压目录下的
etc/config/inventory.xml，找<sqlScript>标签，确认是否存在*rollback*.sql文件 - 若存在，需在
sqlplus / as sysdba中手动运行它，且必须在startup upgrade模式下执行 - 常见坑：有人把
catbundle.sql当成可逆脚本，其实它多数是单向 patch，官方不提供配套 rollback SQL；此时回退补丁后，必须降级整个数据库版本，而非仅靠 opatch
多个补丁叠加安装后，能否只回退中间某一个？
能，但有严格前提：这些补丁之间不能有依赖关系，且目标补丁必须是“最晚应用的补丁之一”。opatch rollback 实际上是按 Patch ID 回退，不是按顺序。但如果补丁 A 依赖 B，而你先回退 A，opatch 会拒绝，除非加 -force（不推荐）。
实操建议：
- 用
opatch lsinventory -bugs_fixed | grep -E "(Patch ID|Bug)"理清补丁间关联 - 优先用
opatch rollback -id <code>Patch_ID明确指定，避免误操作 - 跨版本补丁（如从 19.10 回退到 19.9）风险极高：
opatch不校验兼容性，但 Oracle 内部字典视图或内存结构可能已变更，回退后大概率触发内部错误
真正麻烦的从来不是命令敲得对不对，而是你手上的那个补丁，到底有没有留下可逆的 SQL 脚本，以及它的二进制变更是否被其他未回退补丁悄悄覆盖了。
