直接升级ru补丁不能自动覆盖所有安全漏洞，必须同时满足opatch版本达标、正确选择db/gi/ojvm三类补丁、且ojvm组件启用时须单独应用对应ru；漏任一环节，nessus等工具仍会报出高危漏洞。
直接升级 RU 补丁就能覆盖对应版本内的所有安全漏洞，但前提是 OPatch 版本达标、补丁包选对、且 OJVM 组件（如果启用）必须单独打补丁——漏掉任意一项，Nessus 或其他扫描工具仍会报出“未修复”的高危漏洞。
确认当前 RU 版本和是否启用 OJVM
先查清底细，避免盲目升级。很多漏洞扫描误报，根源是没意识到 OJVM 是独立组件：
- 运行
opatch lsinventory -detail -oh $ORACLE_HOME，看输出中是否有OJVM相关条目； - 执行
select dbms_java.get_jvm_version from dual;，若返回非空值，说明 JVM 已安装，必须同步应用对应版本的 OJVM PSU/RU； - 检查
v$version中的VERSION_FULL，例如19.3.0.0.0对应 RU 19.3，而19.27.0.0.0才是 RU 19.27； - 别只看
sqlplus -v输出——它显示的是 Oracle Home 的初始安装版本，不是当前 RU 级别。
OPatch 必须升级到指定小版本
Oracle 对每个 RU 都硬性要求最低 OPatch 小版本号，低于则 opatch apply 直接失败或静默跳过关键步骤。以 RU 19.27 为例，官方要求 OPatch ≥ 12.2.0.1.47：
- 下载地址固定为 MOS 文档 ID
6880880，文件名类似p6880880_190000_Linux-x86-64.zip； - 解压后用
chown -R oracle:oinstall $ORACLE_HOME/OPatch重置属主，否则后续opatch命令可能因权限拒绝报错OPatch failed with error code 73； - RAC 环境下，grid 和 oracle 用户各自的
$ORACLE_HOME都要分别升级 OPatch，缺一不可； - 验证命令必须带完整路径：
$ORACLE_HOME/OPatch/opatch version，别依赖 PATH 里的旧版本。
DB 补丁与 OJVM 补丁必须分开应用
即使你只关心“数据库漏洞”，只要数据库里装了 JVM（哪怕没主动用），OJVM 漏洞就真实存在，且不会被 DB RU 自动修复：
- DB RU 补丁编号形如
p37960098_190000_Linux-x86-64.zip（对应 RU 19.28），OJVM RU 则是另一个编号，例如p37847857_190000_Linux-x86-64.zip； - 两者应用顺序有约束：先停库 → 应用 DB RU → 启库 → 运行
datapatch→ 再停库 → 应用 OJVM RU → 最后启库 + 再次datapatch； - 如果跳过 OJVM 步骤，
SELECT * FROM DBA_REGISTRY_SQLPATCH里查不到 OJVM 补丁记录，Nessus 仍会标记 CVE-2023-21979 等 JVM 相关漏洞； - OJVM 补丁应用后，必须重启监听器（
lsnrctl reload），否则部分 Java 类加载可能异常。
验证时重点盯住三个地方
补丁“显示成功”不等于漏洞已修复，最终验证必须落到具体对象和输出上：
- 查
dba_registry_sqlpatch，确认新补丁的STATUS是SUCCESS，且DESCRIPTION包含 “Database Release Update” 或 “OJVM Release Update” 字样； - 运行
datapatch -verbose，末尾必须出现Successfully completed，且无ERROR行； - 重新执行漏洞扫描前，先清空 shared pool：
ALTER SYSTEM FLUSH SHARED_POOL;，否则缓存的旧字节码可能导致误判； - 特别注意：某些 CVE（如涉及 TNS listener 的）需额外打 GI 补丁并重启
crsctl stop crs && crsctl start crs，单打 DB 补丁无效。
最易被忽略的是 OJVM 组件的存在性判断和 GI 补丁的联动需求——很多 DBA 只盯着 dba_registry 里的 DB 补丁记录，却忘了 dbms_java 和 crsctl 这两个关键检查点。
