Oracle RAC打PSU补丁遇冲突需谨慎处理：必须显式执行opatch prereq CheckConflictAgainstOHWithDetail -ph ./，结合lsinventory -detail比对基线，区分真冲突与superset关系，严禁-force硬上，优先回滚one-off或按顺序升级完整堆栈。
Oracle RAC 打 PSU 补丁时遇到冲突，不是“不能打”，而是 OPatch 在告诉你：当前环境里已有补丁和你要装的 PSU 在文件、逻辑或修复范围上存在重叠或互斥。跳过冲突检查直接 -force，RAC 极易出现节点分裂、CRS 启动失败或实例反复宕机。
opatch prereq CheckConflictAgainstOHWithDetail 必须显式执行
很多人只运行 opatch prereq 不带参数，或只跑 CheckSystemSpace，结果返回 Prereq check passed 就以为安全——其实根本没触发冲突检测逻辑。RAC 下必须手动指定类型：
- 先进入解压后的 PSU 目录（如
/u01/stage/35212345），确保是解压后目录，不是 ZIP 文件 - 在每个节点分别执行：
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ - 必须先运行
opatch lsinventory -detail，否则比对基线缺失，Conflicting patches可能漏报子补丁或 Bundle 内部项 - 输出中重点看
Conflicting patches列出的编号（如34130714）、Files with conflicts（如$ORACLE_HOME/rdbms/admin/catcon.pl）和Superset patch提示
确认是真冲突还是可覆盖的 superset 关系
Conflict detected 不等于必须中止。OPatch 对 superset 有默认处理逻辑：如果新 PSU 包含旧 one-off 补丁全部修复项，它会自动移除旧补丁、保留新 PSU。但以下情况属于需人工干预的真冲突：
- 两个补丁修改同一文件且变更不可合并（如都改了
ksk.c的同一函数入口） - 冲突补丁来自 Oracle 官方 RU/PSU（如
34130714），说明你漏打了中间版本，不能单独补这个 -
Files with conflicts中的文件近期被手动修改过（比如 DBA 改过catcon.pl），此时新 PSU 覆盖会丢失定制逻辑 - RAC 各节点
opatch lsinventory -detail输出不一致（某节点少一个 PSU），会导致CheckConflictAgainstOHWithDetail误判
真实冲突的两种安全处理路径
别用 opatch apply -force 硬上。RAC 下强制覆盖可能让 CRS 无法识别已安装组件，引发 CRS-4640 或 ORA-29516：
- 若冲突补丁是你自己打的 one-off（如
27923157），且确认无业务依赖，先在对应节点执行：opatch rollback -id 27923157，再重试 PSU - 若冲突补丁是 Oracle 官方 PSU/RU（如
33515361），查 MOS 文档确认该补丁是否属于“必须按顺序安装”的中间版本；若是，放弃单独打当前 PSU，改打完整堆栈（如从19.20.0.0.0升级到19.22.0.0.0） - 所有操作前必须验证：各节点
crsctl check crs全部 ONLINE；$ORACLE_HOME二进制时间戳、patch history 完全一致（用diff -r比对）；ASM 磁盘组无REBALANCING
OPatch 版本与 inventory 一致性常被忽略
很多“冲突”其实是环境没对齐导致的假警报：
-
opatch version必须 ≥ PSU Readme 要求的最低版本（如补丁33515361要求 ≥12.2.0.1.28）；低于就别跑冲突检查，先升级 OPatch -
$ORACLE_HOME/orainst.loc和$ORACLE_INVENTORY/ContentsXML/inventory.xml中的responsefileversion必须是19.0.0.0.0；若仍是12.2.0.1.0，说明是从旧 GI 克隆而来，需用runInstaller -ignoreSysPrereqs -force -silent -attachHome重新注册 Oracle Home - 执行用户必须正确：grid 用户打 GI 补丁，oracle 用户打 DB 补丁；混用会导致 inventory 权限混乱，
opatch lsinventory显示异常
真正棘手的不是冲突本身，而是 RAC 下各节点环境微小差异（比如某个节点多打了一个 one-off、inventory.xml 时间戳晚了几秒、ORACLE_HOME 下某个 .so 文件权限不一致）都会让 CheckConflictAgainstOHWithDetail 输出不可靠。务必把 opatch lsinventory -detail 和冲突检查结果保存为日志，逐行比对节点间差异。
