正常执行opatch lsinventory需不报错、正确显示当前ORACLE_HOME路径及组件信息，底部显示“No patches installed”属正常（表示无补丁），有Patch ID列表更常见；-detail可查Applied on时间、Sub-patches和Files affected；须与dba_registry_sqlpatch交叉验证方为真正生效。
opatch lsinventory 输出什么才算正常
执行 opatch lsinventory 后，只要不报错、能列出 Oracle Home 路径和组件信息，就说明 OPatch 本身可运行。关键看两处：一是顶部的 Oracle Home 路径是否与当前环境一致；二是底部是否出现 No patches installed in this Oracle Home. ——这不代表异常，只是说明没打过任何补丁。生产库常见输出是带一堆 Patch ID 和 Description 的列表，每行对应一个已应用补丁。
lsinventory -detail 能看到哪些关键字段
opatch lsinventory -detail 比基础命令多出三类实用信息：补丁的 Applied on 时间戳（不是安装时间，而是 patch.xml 中声明的发布时间）、Sub-patches 列（显示该补丁是否包含子补丁，比如 PSU 通常带多个子 patch）、以及每个补丁下的 Files affected 行（告诉你改了哪些二进制或 SQL 文件）。注意：这个命令不会显示数据库字典层面的补丁状态，它只反映 $ORACLE_HOME 文件系统的变更。
为什么 lsinventory 看不到刚 apply 的补丁
常见原因有三个：
• ORACLE_HOME 环境变量指向错误路径，导致查的是另一个 Oracle Home
• 补丁执行时用了 -oh 参数指定非默认路径，但 lsinventory 没加对应参数
• 补丁 apply 过程中失败但未报错退出（比如磁盘满导致部分文件写入失败），此时 lsinventory 仍会显示“成功”，但实际缺文件
验证方法：用 opatch lsinventory -oh $ORACLE_HOME 显式指定路径；再检查 $ORACLE_HOME/.patch_storage 下是否有以补丁号命名的子目录；最后比对 lsinventory 输出中的 Files affected 列与实际文件是否存在。
lsinventory 和 dba_registry_sqlpatch 结果不一致怎么办
这是高频误判点：lsinventory 只管文件层，dba_registry_sqlpatch 才反映 SQL 层是否执行成功。例如 PSU 补丁里含 catbundle.sql，如果手动跳过或执行失败，lsinventory 仍显示补丁存在，但 dba_registry_sqlpatch 里 STATUS 是 LOADING 或 FAILED。
必须交叉验证：
• 查 dba_registry_sqlpatch 确认 PATCH_ID 和 STATUS = 'SUCCESS'
• 查告警日志中是否有 catbundle.sql 执行记录及报错
• 对 RAC 环境，每个实例都要单独查 dba_registry_sqlpatch，不能只查一个节点
真正落地的补丁，是这两个视图都对得上，且 lsinventory 里的补丁号在 dba_registry_sqlpatch 中有对应记录——少一个环节，都算没生效。
