Oracle 19c RAC执行RU补丁必须采用滚动升级而非全停集群，因opatch auto仅单节点生效、不自动协调多节点顺序，且全停违反官方支持要求并丧失高可用价值；滚动升级需逐节点维护，GI补丁先于DB补丁执行，OJVM补丁须与DB补丁同节点顺序应用，所有节点需提前通过crsctl check crs校验，并确保root用户SSH互信、AFD启用及OCR备份完备。
必须用 rolling upgrade 而不是全停集群
Oracle 19c RAC 执行 RU 补丁时，opatch auto 默认不等于滚动升级；它只在当前节点生效，且不自动协调多节点顺序。强行全停集群不仅违反 Oracle 官方支持要求（MOS 不受理），还会触发 ORA-01034、ORA-12547 等连接中断错误，更关键的是彻底丧失 RAC 的高可用设计价值。
滚动升级的本质是单节点维护：节点1升级期间，节点2继续承载全部 SQL 请求；等节点1重启上线后，再停节点2升级。整个过程应用无感知的前提是：应用配置了 TAF 或使用 SCAN 监听，并且数据库服务本身未被强制 shutdown。
- GI 补丁必须先于 DB 补丁执行，否则
opatch auto会因组件依赖失败 - OJVM 补丁必须和 DB 补丁在**同一节点上顺序应用**，不能跨节点错开，否则
JAVA$POLICY$TABLE对象失效 - 所有节点必须提前完成
crsctl check crs返回CRS-4638，否则opatch auto可能卡在资源清理阶段
opatch auto 在 RAC 中的实际限制
opatch auto 是半自动工具，不是“一键滚动”。它不校验节点间状态一致性，也不处理 SSH 协调或失败回滚——这些都得人工控制。
常见误操作包括：以为运行一次就能全集群升级、依赖 opatch auto 自动跳转到其他节点、忽略某节点失败后已升级节点不会自动回退。
-
opatch auto只在当前登录节点执行，必须手动 ssh 到每个节点单独运行 - 若某节点因空间不足或冲突检测失败，已成功升级的节点**不会回滚**，需人工介入清理或重试
-
opatch auto不触发datapatch，升级后必须手工在每个节点运行datapatch -verbose - 必须用 root 用户执行，且所有节点 root 用户需配置 SSH 互信（非 grid 用户），否则报
PRVE-0021
关键检查项容易被跳过的三个点
很多故障不是出在升级过程本身，而是预检被跳过——尤其在赶时间时，“看起来没问题”反而最危险。
ocrconfig -showbackup 必须在每个节点验证有最近 7 天内的 OCR 自动备份，不能只看 crsctl query css votedisk 是否在线；磁盘空间不能只查 /u01，还要覆盖 /tmp（补丁解压临时目录）、$ORACLE_BASE/cfgtoollogs（datapatch 日志写入位置）、$GI_HOME/log（GI 升级日志）；无效对象清单必须用 SELECT owner, object_name, object_type FROM dba_objects WHERE status = 'INVALID' 导出比对，不能只信 utlrp.sql 输出 “no errors”。
- 任一目录满会导致
opatch auto静默失败，无明确报错 - 有些 PL/SQL 包编译成功但实际调用时报
PLS-00905，仅靠utlrp无法发现 - 节点间
GI_HOME路径不一致（如 node1 是/u01/app/19.0/grid，node2 是/u01/app/19.1/grid）会直接报OPATCHAUTO-72036拒绝启动
升级后 OCR/VOTING 磁盘组为何突然变慢
这不是错觉。19c 默认启用 ASM Filter Driver（AFD），但升级过程中若未显式启用 AFD，OCR/VOTING 磁盘组会回退到传统 ASMLIB 或 udev 绑定模式，I/O 路径变长，心跳写入延迟明显上升。
验证方式：运行 asmcmd afd_state 应返回 AFD is 'enabled'；若为 disabled，需在所有节点执行 asmcmd afd_configure 并重启 ASM；再用 ocrcheck -config 确认 OCR 位置指向 AFD 路径（如 AFD:/OCR_VOTE），而非原始设备名（如 /dev/mapper/ocr01）。
-
v$asm_diskgroup中TYPE列显示REGULAR而非AFD，是性能下降的直接线索 - AFD 未启用时，
crsctl stat res -t可能出现资源状态抖动，但不报 ERROR，容易被忽略 - rootupgrade.sh 执行后节点短暂失联（40–90 秒）属正常设计行为，但若持续失联超 2 分钟，应立即检查 AFD 和 OCR 配置
