Oracle 19c RAC Grid软件无感知平滑升级步骤

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 互信。注意是 root 用户，而非 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 路径变长，尤其在心跳写入密集时延迟明显上升。

• 如何检查？使用 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//crsconfig）权限仍属于 root。后续若需打 PSU 补丁，补丁写入该路径时会因权限不足而静默失败。届时需手动执行 chown -R grid:oinstall $ORACLE_BASE/crsdata，否则下一次补丁应用可能成为深夜告警的源头。