查DBA_REGISTRY_HISTORY是验证补丁是否注册进数据字典的最权威方法，需确认action='APPLY'、comments含明确补丁标识（如PSU 11.2.0.4.180116）、version与目标一致；若仅有UPGRADE记录则说明数据字典未升级，补丁未真正启用。
查 DBA_REGISTRY_HISTORY 确认补丁是否注册进数据字典
这是最权威的数据库层验证，补丁（尤其是 PSU/PSR）必须运行 catbundle.sql 才会写入该视图；光有文件不代表生效。
- 连接数据库执行：
SELECT action, action_time, namespace, version, id, comments FROM dba_registry_history ORDER BY action_time DESC; - 关键看：
action = 'APPLY'、comments含明确补丁标识（如PSU 11.2.0.4.180116）、version与目标一致（如从11.2.0.3.0升至11.2.0.4.0） - 若只有
UPGRADE记录而无APPLY，说明数据字典未升级，补丁未真正启用
跑 opatch lsinventory 检查二进制层物理安装
它只告诉你补丁文件是否被 OPatch 工具识别并放在 $ORACLE_HOME 下，不反映数据库是否启用功能。
- 执行前确保：
ORACLE_HOME已设、当前用户是oracle、$ORACLE_HOME/OPatch/opatch可执行（必要时chmod +x opatch） - 成功输出特征：
Interim patches (N)行 + 后续列出具体补丁 ID（如26925576），结尾显示OPatch succeeded. - 常见陷阱：
Oracle Home is not set→ 环境变量缺失；There are no Interim patches installed→ 补丁根本没 apply 或 apply 失败后未重试
查 v$version 和 product_component_version 看运行时版本
这两个视图体现实例启动时加载的真实版本，但要注意 Patchset 和 PSU 对版本号的影响完全不同。
- 执行：
SELECT * FROM v$version;或SELECT product, version FROM product_component_version; - Patchset（如
11.2.0.4.0）会改变主版本号，BANNER行应更新；PSU 不会改主版本号，只可能在comments或banner尾部体现（如含PSU字样） - 如果
v$version还是旧版，但DBA_REGISTRY_HISTORY有APPLY记录，大概率是实例没重启 —— PSU/Patchset 都需重启才能生效
别漏掉 dba_objects 验证关键对象有效性
某些补丁会修改或新增数据字典对象（如 DBMS_STATS 包、GV$ 视图），若对象失效，说明补丁虽注册但脚本执行异常。
- 简单检查：
SELECT object_name, status FROM dba_objects WHERE object_name IN ('DBMS_STATS', 'DBMS_SQLTUNE') AND owner = 'SYS' AND status != 'VALID'; - 若返回任何行，说明对应对象编译失败，需手动运行
utlrp.sql或排查日志中的 ORA- 错误 - 尤其注意：Patchset 升级后首次启动常触发大量无效对象，不处理会导致后续统计信息收集、AWR 报告等功能异常
补丁验证不是单点动作，DBA_REGISTRY_HISTORY、opatch lsinventory、v$version 和 dba_objects 四者缺一不可。最容易被跳过的是重启实例和 utlrp.sql 编译，而这恰恰是“看起来装了，实际用不了”的高频原因。
