opatchauto无法真正滚动升级RU，因其强制停所有节点服务，不支持业务不中断；根本原因是RU含字典变更、PDB校验及datapatch自动触发等强一致性要求，必须全节点统一版本。
opatchauto 不能真正实现 rac 环境下的“滚动”补丁——它会强制停掉所有节点的数据库和集群服务，不存在部分节点在线、部分节点升级的情况。所谓“滚动”，只是指命令在各节点上顺序执行，而非业务不中断。
为什么 opatchauto 无法滚动升级 RU
Oracle 官方明确限制：opatchauto 对 RU（Release Update）类补丁不支持滚动逻辑，根本原因在于 RU 包含字典变更、PDB 级校验、datapatch 自动触发等强一致性要求。一旦某个节点运行旧 RU，v$version 就会显示混合版本，registry$sqlpatch 状态可能不一致，后续备份或升级极易失败。
常见错误现象包括：
OPATCHAUTO-72033: This patch is not applicable for auto patching- 执行后
datapatch -verbose报错或跳过 SQL 变更 - RAC 各节点
SELECT * FROM v$version返回不同 RU 版本号
opatchauto 执行前必须同步完成的四件事
缺一不可，否则大概率中途失败或状态不一致：
- 所有节点的
$GI_HOME/OPatch和$ORACLE_HOME/OPatch必须升级到 Oracle 要求的最低版本（如 RU 19.22 要求 OPatch ≥ 12.2.0.1.40），且需用root用户操作 GI_HOME，oracle或grid用户操作 DB_HOME -
/u01/app/oraInventory/ContentsXML/oui-patch.xml在所有节点需有读写权限（常见报错Permission denied就卡在这） - 补丁包必须解压到各节点**相同路径**（如统一为
/tmp/34130714），不能依赖opatchauto推送 - GI 补丁与 DB 补丁版本必须严格匹配（例如 DB 打 19.22，GI 也必须是 19.22），否则
crsctl check cluster可能报CRS-4639
opatchauto 执行时的关键动作与陷阱
命令本身简单，但执行逻辑和验证点极易被忽略：
- 必须以
root用户执行：opatchauto apply /tmp/34130714（不能用oracle或grid用户直接跑） - 每个节点单独执行，**不能并行**；节点 1 成功后再执行节点 2，否则集群资源争用会导致
CRS-6015或OHASD崩溃 - 执行过程会自动调用
crsctl stop crs和crsctl start crs，但不会自动运行datapatch -verbose—— 这步必须人工补上，且需在**所有实例启动后、所有 PDB OPEN 后**立即执行 - 若中途失败，用
opatchauto resume续跑前，先确认/u01/app/oraInventory/ContentsXML/oui-patch.xml权限、磁盘空间、以及 GI 是否已完全重启
打完补丁后唯一可信的验证方式
别只看 opatch lsinventory 或命令返回 OPatch succeeded —— 这些都不可靠。真正有效的验证只有：
- 查
registry$sqlpatch：每条记录的status必须全为SUCCESS，且action_time是本次 RU 的时间戳 - 查
v$database.current_scn与datapatch -verbose最后输出的 SCN 是否一致 - RAC 所有节点分别执行：
SELECT BANNER_FULL FROM v$version，确保输出完全相同（含 RU 编号，如19.22.0.0.0） - OJVM 补丁需额外检查
dba_registry_sqlpatch中COMP_ID = 'JAVAVM'的状态
最容易被跳过的动作，就是没在所有 PDB OPEN 后立刻运行 datapatch -verbose。一旦漏掉，registry$sqlpatch 里会残留 APPLYING 状态，后续任何升级都可能被阻塞。
