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 -fon one node），观察VIP漂移时间、数据库重连是否gv$cluster_interconnects是否无丢包——这才是“平滑”的实证
最容易被忽略的是：升级完成后，gridSetup.sh生成的新OHASD日志目录（$ORACLE_BASE/crsdata/<host>/crsconfig）权限仍属root，若后续打PSU补丁需写入该路径，会因权限不足静默失败。必须手动chown -R grid:oinstall $ORACLE_BASE/crsdata，否则下一次补丁就是深夜告警。
