oracle 19c rac执行ru补丁必须走滚动升级路径，因rac架构设计支持单节点维护，官方要求按节点顺序升级以保障服务在线；全停集群不仅丧失高可用价值，还会引发ora-01034等错误且失去mos技术支持。
直接说结论：oracle 19c rac生产环境执行ru补丁更新，必须走滚动升级（rolling upgrade）路径，不能停整个集群；否则业务中断时间不可控，且违反oracle官方支持要求。
为什么必须用 rolling upgrade 而不是全停集群
RAC本质是多节点共享存储的高可用架构，设计目标就是允许单节点维护。Oracle明确要求RU补丁在RAC中必须按节点顺序升级——先升级节点1，再升级节点2（依此类推），期间数据库服务始终在线。强行全停集群不仅失去RAC价值，还会触发ORA-01034、ORA-12547等连接中断类错误，且无法通过MOS开case获得技术支持。
- 滚动升级时，未升级节点继续提供SQL服务，应用无感知（前提是应用层配置了TAF或SCAN监听）
- GI补丁必须先于DB补丁升级，否则
opatch apply会因组件依赖失败 - OJVM补丁必须和DB补丁在同一节点上顺序应用，不能跨节点错开，否则出现
JAVA$POLICY$TABLE对象失效
opatch auto 在 RAC 中的实际限制
opatch auto看似“全自动”，但在RAC生产环境里它只是个半自动工具——它不处理节点间协调，也不校验跨节点状态一致性。你必须手动控制执行顺序和时机。
- 执行前需确认所有节点
crsctl check crs返回CRS-4638: Oracle High Availability Services is online -
opatch auto只在当前节点生效，不会自动ssh到其他节点执行；必须登录每个节点单独运行 - 若某节点执行失败（如空间不足、冲突检测失败），
opatch auto不会回滚已升级节点，需人工介入 - 升级后必须手工运行
datapatch，opatch auto不触发该步骤
关键检查项容易被跳过的三个点
很多故障源于“看起来没问题”的检查项被跳过，尤其在赶时间时。
-
ocrconfig -showbackup必须在每个节点都验证有最近7天内的OCR自动备份，而不仅是看crsctl query css votedisk是否在线 - 磁盘空间检查不能只看
/u01，必须包含/tmp（解压补丁临时目录）、$ORACLE_BASE/cfgtoollogs（datapatch日志写入位置）、$GI_HOME/log（GI升级日志），任一目录满会导致opatch静默失败 - 无效对象清单要用
SELECT owner, object_name, object_type FROM dba_objects WHERE status = 'INVALID';导出，不能只依赖utlrp.sql输出“no errors”就认为干净——有些PL/SQL包编译成功但实际调用时报PLS-00905
datapatch 必须在所有节点DB实例都启动后才运行
这是最容易出错的环节：有人在节点1升级完DB补丁、启动实例后立刻运行datapatch，结果只打上了节点1的字典变更，节点2启动后仍用旧字典，后续出现ORA-00600 [kqlnrc_1]或视图查询结果不一致。
- 正确顺序：节点1 GI → 节点1 DB → 节点1
sqlplus / as sysdba→STARTUP→ 节点2 GI → 节点2 DB → 节点2STARTUP→ 所有节点都OPEN状态 → 任一节点执行datapatch -verbose -
datapatch输出里必须看到类似Applied Patches: 37642901且每行末尾是SUCCESS，而不是SKIPPED - 如果
datapatch中途报错（如ORA-29855），不要重试，先查$ORACLE_HOME/cfgtoollogs/sqlpatch下最新log，常见原因是PDB未open或catcon.pl权限不足
真正难的不是命令怎么敲，而是每个节点的状态同步、每个检查项的交叉验证、以及补丁后字典变更的全局一致性——这些没法靠脚本自动兜底，得人盯住。
