oracle 19c rac中ru补丁必须通过opatch apply加datapatch手动逐节点分步执行，严禁使用opatchauto；否则registry$sqlpatch无记录，漏洞扫描持续告警。
不能直接用 opatchauto 打 RU 补丁，必须分步执行 opatch apply + datapatch，否则 registry$sqlpatch 里看不到记录，漏洞扫描仍会告警。
确认当前 RU 版本和 OJVM 是否启用
别只看 sqlplus -v 输出——它显示的是初始安装版本，不是当前 RU 级别。真实 RU 版本藏在 v$version.VERSION_FULL 里：
- 运行
SELECT VERSION_FULL FROM v$version;，比如返回19.27.0.0.0就说明已是 RU 19.27 - 查 OJVM：执行
select dbms_java.get_jvm_version from dual;，有返回值即已启用，必须单独打对应 OJVM RU 补丁 - 再跑一遍
$ORACLE_HOME/OPatch/opatch lsinventory -detail，确认输出中是否含OJVM字样——漏掉这个，Nessus 会继续报 CVE-2023-21979 这类漏洞
OPatch 必须先升级到指定小版本
Oracle 对每个 RU 都硬性要求最低 OPatch 小版本号。例如 RU 19.28 要求 OPatch ≥12.2.0.1.45，低于则 opatch apply 可能静默跳过关键步骤。
- 下载地址固定为 MOS 文档 ID
6880880，文件名类似p6880880_190000_Linux-x86-64.zip - 解压后必须用
chown -R oracle:oinstall $ORACLE_HOME/OPatch重置属主，否则可能报错OPatch failed with error code 73 - RAC 环境下，
grid和oracle用户各自的$ORACLE_HOME都要分别升级，缺一不可 - 验证时务必用完整路径：
$ORACLE_HOME/OPatch/opatch version，别依赖PATH里的旧版本
RU 补丁必须手动逐节点应用（RAC 场景）
opatchauto 在 19c RAC 中不支持 RU 补丁滚动升级——这是硬限制，不是操作错误。看到 Metalink 写 “supported”，得核对适用版本，12.2/18c 的文档不适用于 19c RU。
- 先停一个节点的数据库实例和 CRS：
crsctl stop crs - 对该节点的
$ORACLE_HOME执行opatch apply - 重启该节点 CRS 和数据库，再运行
datapatch -verbose - 验证：
SELECT PATCH_ID, STATUS FROM registry$sqlpatch WHERE BUNDLE_SERIES = 'RU';，状态必须是AP - 重复以上步骤到下一个节点，严禁跨节点并发操作
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 补丁应用后，必须执行
lsnrctl reload，否则部分 Java 类加载失败 - 漏掉 OJVM 步骤，
DBA_REGISTRY_SQLPATCH里查不到对应记录，安全扫描工具照常报高危
最易被忽略的是 comps.xml 文件校验失效问题：如果客户环境曾手动删改过 $ORACLE_HOME/inventory/ContentsXML/comps.xml，opatch apply 可能看似成功，但后续组件注册全失效，导致 ORA-00600[ktbdchk1] 或归档卡在 +RECO。补丁前务必用 opatch lsinventory -detail 确认输出干净无异常。
