先说一个核心判断：Oracle 19c RAC的Grid平滑升级，关键不在于能否实现“完全无感知”，而在于如何将业务影响压缩到秒级。整个路径的核心其实只有三件事——选择正确的Rolling升级路径、准确把握opatchauto的调用时机，以及升级过程中避免触发OCR/VOTING磁盘组的Rebalance。只要这三方面把控到位，问题就能迎刃而解。
为什么rootupgrade.sh执行后节点会短暂失联
这其实是RAC集群重启CRS Stack的必经环节。rootupgrade.sh底层操作很直接：先执行crsctl stop crs清理旧进程，再通过crsctl start crs重新拉起新版资源。整个过程通常耗时40到90秒不等。在此期间，该节点上的VIP、SCAN Listener、数据库实例全部不可用——但这属于正常现象，并非异常。
- 失联并不代表失败，而是RAC集群的正常设计行为。只要集群中其他节点仍在正常运行，SCAN VIP和应用连接会自动漂移到存活节点，业务端基本感知不到影响。
- 但有一个关键前提：切勿在单节点RAC或集群中只剩1个存活节点的状态下执行升级——否则将直接导致整个集群中断。
- 另外，升级前务必确认
crsctl check cluster -all输出显示所有节点状态均为ONLINE，否则升级很可能在资源清理阶段卡住无法继续。
OPatch auto滚动升级时最常踩的三个坑
Oracle官方推荐使用opatchauto进行GI+DB的联合滚动升级，这个工具本身功能强大，但对环境高度敏感，任何一个环节未到位都可能导致失败。
- 第一个隐患：所有节点的root用户必须配置好SSH互信。注意，不是grid用户，而是root。如果未配置，
opatchauto在升级到第二个节点时会报错PRVE-0021: SSH connectivity not working，直接中断流程。 - 第二个坑：如果环境中配置了ADG，则必须先完成备库补丁安装并验证同步正常，才能在主库执行升级。否则
opatchauto检测到DG延迟就会中止升级，不留任何缓冲余地。 - 第三个是路径问题：如果集群中各节点的GI_HOME路径不一致，例如node1为
/u01/app/19.0/grid，node2为/u01/app/19.1/grid，那么opatchauto会直接拒绝启动滚动流程，并报错OPATCHAUTO-72036: GI home path mismatch across nodes。这一点在规划安装时就需要提前关注。
升级后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）。很多人因忽略这一步，后续排查性能问题耗费大量时间。 - 如果未启用AFD，
v$asm_diskgroup中TYPE列可能显示REGULAR而非AFD，这正是性能下降的直接线索。
如何验证升级后集群真正“平滑”而非“侥幸”
很多团队升级后只跑通几个SQL就认为万事大吉，但真正的风险往往隐藏在后台资源调度的细节中。
- 第一步：执行
crsctl stat res -t -w "name like 'ora.%'" | grep -E "(OFFLINE|FAILED)"，确保没有任何资源处于异常状态。 - 第二步：查询
gv$asm_operation，确认STATE = 'NORMAL'，且没有残留的REBALANCE任务。即使EST_MINUTES显示为0，也要等SOFT=0后才能认为安全。 - 最关键的一步：在业务低峰期，手动触发一次节点驱逐（在一个节点上执行
crsctl stop crs -f）。然后观察VIP漂移时间、数据库重连情况，以及gv$cluster_interconnects是否有丢包。这才是“平滑”二字的实证。
还有一个细节容易被忽略：升级完成后，gridSetup.sh生成的新OHASD日志目录（$ORACLE_BASE/crsdata/）权限仍属于root。如果后续需要打PSU补丁，补丁写入该路径时会因权限不足而静默失败。届时只能手动执行chown -R grid:oinstall $ORACLE_BASE/crsdata。否则下一次补丁应用很可能成为深夜告警的源头。
