必须在解压补丁后运行，因opatch prereq checkconflictagainstohwithdetail需扫描解压后的补丁目录（如/tmp/32507738）与当前oracle home的兼容性，未解压则报错135或“no patch directory found”。
opatch prereq CheckConflictAgainstOHWithDetail 必须在解压补丁后运行
补丁冲突检测不是靠猜，而是由 opatch prereq CheckConflictAgainstOHWithDetail 主动扫描当前 Oracle Home 与待装补丁之间的兼容性。这个命令必须在补丁 ZIP 解压完成、得到具体目录（如 /tmp/32507738）之后才能执行，否则会报 OPatch failed with error code 135 或提示“no patch directory found”。
- 先解压补丁包：
unzip p32507738_122010_Linux-x86-64.zip -d /tmp/ - 再切换到 $ORACLE_HOME/OPatch 目录下执行：
./opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /tmp/32507738 - 若输出含
Prereq check passed，说明无硬冲突；若出现Conflicting patches行，则需先回滚对应补丁或跳过该补丁
冲突检测失败常见原因和对应动作
实际执行 opatch prereq CheckConflictAgainstOHWithDetail 报错时，多数不是补丁本身有问题，而是环境没对齐。最常踩的坑是权限、路径和用户身份不匹配。
-
OPatch failed with error code 254：通常是当前用户（如oracle）没有读取-phBaseDir下补丁文件的权限，用ls -l /tmp/32507738确认属主和读权限 - 在 RAC 环境中只对一个节点运行了检测：必须在每个节点、分别以
grid和oracle用户重复执行，因为 GI HOME 和 DB HOME 是分离的 - 误把 README.html 路径当补丁根目录传入：
-phBaseDir必须指向解压后的顶层目录（含etc/、files/子目录），不是 ZIP 文件本身，也不是 README 所在路径
为什么不能跳过冲突检测直接 opatch apply
跳过检测强行打补丁，轻则 opatch apply 中途失败并残留临时文件，重则导致数据库启动报 ORA-00704 或 ORA-01092，甚至引发数据字典损坏。Oracle 官方明确要求 RU/RUR 补丁必须通过此检查，尤其涉及 OJVM 补丁时，冲突可能引发 JVM 内存结构不一致。
- 某些冲突是“软冲突”（比如两个补丁修改同一文件但不重叠行），
opatch prereq不报错，但opatch apply仍可能拒绝——此时需看补丁 README 是否注明 “requires prior rollback of patch XXX” - 检测通过 ≠ 补丁一定成功：它只保证“无已知冲突”，不校验磁盘空间、SQL 执行权限、无效对象数量等后续环节
检测前必须确认 OPatch 版本够新
opatch prereq CheckConflictAgainstOHWithDetail 在旧版 OPatch（如低于 12.2.0.1.25）中根本不存在，强行运行会提示 Unknown prereq command。这不是拼写错误，是功能缺失。
- 查版本：
opatch version，输出应为类似OPatch Version: 12.2.0.1.40 - 升级方式：下载
p6880880_*.zip，解压覆盖 $ORACLE_HOME/OPatch，注意保留原OPatchbak备份目录 - RAC 环境中 grid 和 oracle 用户的 OPatch 都要升级，且版本号建议完全一致，避免跨层调用时行为不一致
CheckConflictAgainstOHWithDetail 只检查代码层冲突，不验证组件依赖链。这时候得人工核对补丁 README 的 “Prerequisites” 小节，漏掉这一条，后续 @?/rdbms/admin/catbundle.sql 就会卡住。
