Oracle 19c RAC的RU补丁无法真正“零感知”：滚动升级虽支持，但每个节点需执行crsctl stop/start crs（停CRS约60–90秒），触发VIP漂移、SCAN监听瞬断及连接中断；OCR重配置阶段集群短暂不可用（10–20秒），且存在DBMS_QOPATCH格式变更、Java对象失效、AWR间隔重置等兼容性风险。
Oracle 19c RAC上不能直接“零停机”应用RU（Release Update）补丁——至少不是传统意义上的全程不停业务。RU补丁包含数据库二进制、OJVM、GI组件更新，其中GI（Grid Infrastructure）和数据库实例的滚动升级虽支持，但**必须触发一次OCR/Voting Disk的在线重配置，且所有节点需短暂重启CRS Stack**，这会导致VIP漂移、SCAN Listener瞬断、已建立连接中断（应用层需重连）。所谓“零停机”，实际是指业务连接可自动恢复、事务不丢失、RAC集群服务不整体下线。
为什么19c RAC的RU不能真正“零感知”
Oracle官方明确说明：19c RU（如19.22、19.23）要求在应用前执行opatchauto apply，该命令会自动判断是否需滚动升级。但即使选择滚动模式，仍存在两个硬性中断点：
- 每个节点执行
crsctl stop crs再crsctl start crs时，本地CRS服务停约60–90秒，期间该节点上的ASM实例、数据库实例、监听器全部不可用； - OCR备份和投票盘校验阶段（通常在首个节点升级后触发），集群会短暂进入“reconfiguration”状态，
crsctl check cluster可能返回CRS-4639: Could not contact Oracle High Availability Services，持续10–20秒； - 应用层若未启用TAF（Transparent Application Failover）或Fast Connection Failover（FCF），JDBC/ODBC连接池会报
ORA-03113: end-of-file on communication channel，需依赖连接池自动重试逻辑恢复。
滚动应用RU的实操关键步骤
跳过预检等于埋雷。必须按顺序执行，否则opatchauto会在中途中止：
- 确认GI和DB HOME均为同一版本（
crsctl query crs activeversion和$ORACLE_HOME/OPatch/opatch lsinventory）； - 备份OCR和Voting Disk：
ocrconfig -showbackup+crsctl replace votedisk（建议先写入NFS或ASM别名盘）； - 禁用自动重启策略（防升级中断后CRS自启失败节点）：
crsctl modify resource "ora.crsd" -attr "AUTO_START=never"； - 在首个节点运行：
opatchauto apply /path/to/ru/2026jul22 -nonrolling（注意加-nonrolling强制单节点先行，避免误触发全集群停）； - 待首节点成功后，手动逐节点执行：
opatchauto apply /path/to/ru/2026jul22 -oh $GI_HOME（仅升级GI），再-oh $ORACLE_HOME（再升DB）；
最容易被忽略的三个兼容性陷阱
补丁本身能装上，不代表业务能跑通。以下三项必须在补丁前验证：
-
DBMS_QOPATCH包在RU后行为变更：19.21+版本中，DBMS_QOPATCH.GET_OPATCH_INSTALL_HISTORY()返回格式从XML改为JSON，若监控脚本硬解析XML结构，会抛ORA-31011: XML parsing failed； - Java对象失效：RU含OJVM更新，所有
CREATE JAVA或DBMS_JAVA加载的类会被invalidated，首次调用时触发隐式loadjava，若应用未设超时，可能卡住线程； - AWR快照间隔突变：某些RU（如19.20→19.21）会重置
dbms_workload_repository.modify_snapshot_settings中的interval为默认60分钟，若原环境设为15分钟，升级后AWR数据粒度变粗，性能分析将失真。
真正影响成败的，从来不是补丁安装那几十分钟，而是OCR备份是否可用、连接池是否配置了3秒内重连、以及有没有人记得检查DBA_REGISTRY_SQLPATCH里每条记录的STATUS是不是SUCCESS而不是LOADING——后者意味着某张系统表升级失败，但opatchauto没报错。
