opatch prereq是强制前置步骤，跳过将导致90%安装失败；它通过比对补丁元数据识别文件覆盖、版本错位及组件重叠风险，而opatch apply仅执行覆盖不校验，无法替代prereq的冲突发现与定位能力。
补丁冲突检测不是可选步骤，而是 opatch apply 前必须通过的门槛；跳过它，90% 的安装失败都源于未识别的已存在补丁覆盖、版本错位或组件重叠。
为什么 opatch prereq 比直接 opatch apply 更关键
Oracle 补丁包本身不自带“智能覆盖逻辑”，opatch 仅按元数据比对已安装补丁的编号、子集关系和适用组件。若已有补丁（比如某个单补丁）已修改了 libnnz11.so，而新 PSU 也含同名文件但版本不同，opatch apply 会直接报错退出，且不自动提示该冲突来自哪个旧补丁——这个定位工作必须靠 prereq 提前完成。
-
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /path/to/patch是最常用命令，它会扫描整个$ORACLE_HOME并逐个比对补丁元数据 - 输出里出现
Conflicts with patches: [12345678]不代表不能装，而是说明需先回滚12345678或确认它是否已被包含在新 PSU 中（查补丁 README 的 “Included Patches” 小节） - 若输出含
Prereq check failed但没列具体补丁号，大概率是OPatch版本太低——例如 11.2.0.4 环境下，opatch必须 ≥ 11.2.0.3.20，老版本压根无法解析新版 PSU 的patch.xml结构
lsinventory 输出怎么看才不漏掉隐藏冲突
很多人只扫一眼 opatch lsinventory 列出的补丁编号，却忽略三类高危信号：
- 状态为
applied but not active的补丁：说明catbundle.sql没跑完，二进制层已更新但数据库层未生效，此时新 PSU 可能因依赖未就绪而拒绝安装 - 同一编号多次出现（如
12345678出现两次）：代表曾打过又回滚过，但部分文件残留，prereq可能误判为“已存在” - 组件名含
OJVM但当前 PSU 不含该组件：例如你正装标准 DB PSUp33477185，但lsinventory里有OJVM补丁，就得单独评估是否需要同步更新 OJVM 包，否则 Java 存储过程可能运行异常
真实环境里最容易被跳过的三个检查点
这些动作不耗时，但缺一不可：
- 确认
$ORACLE_HOME/inventory/ContentsXML/comps.xml中的oracle.rdbms组件版本与当前数据库版本严格一致（如 11.2.0.4.0），否则prereq会因组件描述不匹配直接失败 - 检查
$ORACLE_HOME/.patch_storage目录大小，若 >2GB，说明历史补丁日志堆积过多，opatch解析时可能内存溢出——临时清空该目录下非当前补丁的子目录即可（保留patch_<date></date>最近三个） - 在 RAC 环境中，必须分别以
grid和oracle用户执行prereq，因为 OCR、ASM 补丁和数据库补丁分属不同 Oracle Home，混用用户会导致冲突检测范围缺失
冲突检测真正的难点不在命令怎么写，而在于读懂 prereq 报出的每个“conflict”背后是文件覆盖风险、还是版本依赖断链、抑或只是元数据残留——这需要对照补丁 README 里的 Interim Patch Conflicts 和 Bundle Patch Dependencies 两节交叉验证，而不是凭编号盲目回滚。
