oracle 19c的ru补丁不能用opatch auto滚动应用，必须按顺序执行opatch apply、启动数据库、运行datapatch；rac需逐节点同步补丁并确保gi版本严格匹配，最终通过registry$sqlpatch和v$pdbs验证生效。
oracle 19c 的 ru（release update）补丁不能用 opatch auto 滚动应用 —— 这个命令在 19c 中已被弃用，强行使用会失败或跳过关键步骤。
为什么 opatch auto 在 19c 不再适用
从 Oracle 19c 开始，RU 补丁（如 19.22、19.23）必须通过 opatch apply + datapatch 组合完成，opatch auto 已被标记为“仅用于旧版本兼容”，实际执行时会拒绝处理 RU 类型补丁包，并报错：
OPATCHAUTO-72033: This patch is not applicable for auto patching.
根本原因是 RU 补丁结构包含数据库字典变更、SQL 脚本和 RAC-aware 的协调逻辑，opatch auto 缺乏对 datapatch 自动触发、PDB 级别校验、rolling restart 序列的完整支持。
正确流程：分三步手动执行 RU 应用
适用于单机或 RAC 环境，需按顺序执行，缺一不可：
- 停用所有监听器和数据库实例（RAC 需逐节点停，保留一个节点在线可选，但 RU 不支持真正意义上的“滚动”——它要求所有实例重启后统一运行同一 RU 版本）
- 用
opatch apply应用补丁到 $ORACLE_HOME：$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local（加-local避免误触集群资源） - 启动数据库（含所有 PDB），立即运行
datapatch -verbose：该步骤执行 SQL 变更，若跳过或失败，v$database中current_scn和registry$sqlpatch状态将不一致，后续升级或备份可能出错
RAC 环境下特别注意的四个点
RAC 并非不能打 RU，而是不能靠 opatch auto “自动滚动”。真实约束来自补丁本身和 Oracle 的一致性要求：
-
opatch apply必须在每个节点单独执行，且所有节点的 $ORACLE_HOME 必须先同步补丁文件（建议用rsync或共享 NFS，不要依赖 OPatch 自带的推送） - 不能只升级部分节点：哪怕只有一个实例运行旧 RU，
SELECT * FROM v$version就会显示混合版本，datapatch在任一节点执行都会尝试同步全部实例，失败概率极高 - GI（Grid Infrastructure）补丁必须与 DB RU 版本严格匹配（例如 DB 打 19.22，GI 也必须是 19.22），否则
crsctl check cluster可能报CRS-4639类错误 - 打完后检查
registry$sqlpatch中每条记录的status是否全为SUCCESS，且action_time是最新 RU 的时间 —— 这比看opatch lsinventory更可靠
最容易被忽略的验证动作
很多人以为 opatch lsinventory 显示补丁 ID 就算成功，其实最关键的验证藏在数据库内部：
- 连接 CDB$ROOT 后执行：
SELECT patch_id, version, status, action FROM registry$sqlpatch WHERE action_time = (SELECT MAX(action_time) FROM registry$sqlpatch); - 确认返回的
version字段精确匹配你安装的 RU 号（如19.22.0.0.0），而非19.0.0.0.0这类占位符 - 检查
v$pdbs中每个 PDB 的STATUS是否为READ WRITE，且无RESTRICTED标记 —— RU 补丁后 PDB 若处于 MOUNTED 状态，说明datapatch未在其容器内执行
没走完这三步验证，补丁就算物理上装上了，也等于没生效。
