Oracle RAC节点维护如何避免业务中断

节点维护前必须确认TAF真正启用且FAILOVER_MODE嵌套在CONNECT_DATA下，RAC One Node需用relocate而非shutdown，维护前应调小RESUMABLE_TIMEOUT并验证私网心跳连通性。

节点维护前必须确认 TAF 是否真正启用

没配 FAILOVER_MODE 的 RAC 集群，哪怕写了 FAILOVER=ON，维护时也会断连。TAF（Transparent Application Failover）不是可选功能，而是长连接不中断的唯一路径。

1. FAILOVER_MODE 必须嵌套在 CONNECT_DATA 下，写在 DESCRIPTION 层级会被 Oracle 静默忽略
2. 典型有效配置：(FAILOVER_MODE=(TYPE=session)(METHOD=basic)(RETRIES=3)(DELAY=5))
3. 验证方式：连接后查 v$session 的 failover_type 和 failover_method 字段，非空才表示生效
4. JDBC URL 中若用 oracle.jdbc.replay=false 或驱动版本过低（如 ojdbc6），可能绕过 TAF，需升级到 ojdbc8+ 并禁用 replay

RAC One Node 场景下 relocate 比 shutdown 更安全

如果用的是 RAC One Node（单实例集群模式），别直接停库——它支持在线 relocate，即把数据库服务从待维护节点平滑迁移到另一节点，全程业务无感知。

1. 执行 srvctl relocate database -d <db_name> -n <target_node>，命令返回成功即完成迁移
2. 迁移过程会自动触发 TAF 切换，客户端连接保持，旧节点上的会话逐步 drain，不强制 kill
3. 注意：目标节点必须资源充足，crsctl status resource -t 要确认 ora.<db_name>.db 已 online 在目标节点
4. relocate 后原节点仍可继续运行 CRS，但数据库资源已释放，可打补丁或重启 OS，不影响业务

维护窗口内避免触发 resumable 挂起导致事务卡住

维护期间若恰有大事务在跑（如批量导入、索引重建），而空间不足，RESUMABLE_TIMEOUT 设得过大（比如 3600），会导致事务挂起并持续占锁，反而拖慢整体恢复节奏。

1. 建议维护前临时调小该参数：ALTER SYSTEM SET RESUMABLE_TIMEOUT = 300 SCOPE=BOTH;（5 分钟超时）
2. 对关键批任务，提前检查 DBA_RESUMABLE 视图，确认无 active 挂起项；若有，手动 ALTER SESSION DISABLE RESUMABLE 或中止会话
3. RAC 环境下必须逐节点执行 ALTER SYSTEM，不能只改一个 instance
4. 维护结束后再恢复原值，避免影响日常 DML

私网心跳验证比 ping VIP 更关键

维护后重启节点或网络服务，最容易被忽略的是私网（interconnect）连通性。tnsping 或 sqlplus 连 VIP 成功，不代表集群能正常加入——CSSD 心跳失败照样驱逐节点。

1. 用 oifcfg getif 确认私网接口名（如 bond0）是否被正确识别，且绑定 IP 与 crsctl check cluster -all 显示一致
2. 执行 ping -I bond0 -c 5 <peer_private_ip>，丢包率为 0 才算达标；仅 ping 公网 VIP 或 hostname 完全无效
3. 检查 /var/log/oracle/crsd/crsd.log 里是否有 CRS-1601（CSSD 无法加入集群）或 ORA-29702（心跳超时）
4. 若用多路径私网，拔掉一根线后必须观察 crsctl stat res -t | grep network 是否仍为 ONLINE，否则说明冗余未生效

真实维护中最容易卡住的，不是命令会不会敲，而是私网连通性没验证、TAF 配置被当成装饰、resumable 超时设得像“永远等待”。这些点不手工确认，自动化脚本跑得再快也没用。