怎样在Oracle 19c RAC上进行无感知的Grid软件平滑升级

rootupgrade.sh执行后节点短暂失联是因重启CRS Stack（crsctl stop crs → start crs），耗时40–90秒，属正常设计行为；须确保升级前crsctl check cluster -all全节点ONLINE，且不可在单节点或仅1存活节点时执行。

不能做到真正无感知，但可将业务影响压缩到秒级——关键在滚动升级路径、opatch auto的正确调用时机，以及避开ocr/voting磁盘组rebalance。

为什么rootupgrade.sh执行后节点会短暂失联

这是RAC集群重启CRS Stack的必经过程：rootupgrade.sh最终会触发crsctl stop crs → 清理旧进程 → crsctl start crs。整个过程通常耗时40–90秒，期间该节点上的VIP、SCAN Listener、数据库实例全部不可用。

• 失联不是失败，是设计行为；只要其他节点仍在运行，SCAN VIP和应用连接会自动漂移到存活节点
• 切勿在单节点RAC或仅剩1个存活节点时执行——这会导致整个集群中断
• 确认crsctl check cluster -all在升级前所有节点状态为ONLINE，否则升级可能卡在资源清理阶段

OPatch auto滚动升级时最常踩的三个坑

Oracle官方推荐用opatchauto进行GI+DB联合滚动升级，但它对环境非常敏感：

• 必须确保所有节点root用户已配置SSH互信（非grid用户），否则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路径变长，尤其在心跳写入密集时延迟明显上升。

• 检查是否启用AFD：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 on one node），观察VIP漂移时间、数据库重连是否gv$cluster_interconnects是否无丢包——这才是“平滑”的实证

最容易被忽略的是：升级完成后，gridSetup.sh生成的新OHASD日志目录（$ORACLE_BASE/crsdata/<host>/crsconfig）权限仍属root，若后续打PSU补丁需写入该路径，会因权限不足静默失败。必须手动chown -R grid:oinstall $ORACLE_BASE/crsdata，否则下一次补丁就是深夜告警。