在执行 Oracle RAC 节点维护之前，必须先确认 TAF 已经真实生效，并确保 FAILOVER_MODE 是正确嵌套在 CONNECT_DATA 之下。对于 RAC One Node 场景，应使用 relocate 命令进行平滑迁移，而不是直接执行 shutdown。另外，维护前还应适当调低 RESUMABLE_TIMEOUT 的数值，并提前验证私网心跳链路的连通性，才能尽可能避免业务中断。

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

即使已经配置了 FAILOVER=ON，但如果 RAC 集群没有正确设置 FAILOVER_MODE，在节点维护、重启或切换时仍然可能发生连接中断。TAF（Transparent Application Failover）并不是可选项，而是 Oracle RAC 节点维护中保障长连接连续性、降低业务中断风险的重要机制。

• FAILOVER_MODE 必须嵌套在 CONNECT_DATA 下方；如果写在 DESCRIPTION 层级，Oracle 往往会静默忽略，导致配置看似存在却实际无效
• 常见且有效的配置示例：(FAILOVER_MODE=(TYPE=session)(METHOD=basic)(RETRIES=3)(DELAY=5))
• 验证方法：连接数据库后查询 v$session 视图中的 failover_type 和 failover_method 字段，只有字段非空才说明 TAF 已真正生效
• 如果 JDBC URL 中使用了 oracle.jdbc.replay=false，或者驱动版本过低（例如 ojdbc6），可能无法按预期走 TAF，建议升级到 ojdbc8+ 并关闭 replay 相关影响

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

如果当前环境使用的是 RAC One Node（单实例集群模式），维护时不要直接停库。更推荐使用在线 relocate，将数据库服务从待维护节点平滑迁移到目标节点，从而实现更安全的节点维护，尽量做到业务无感切换。

• 执行 srvctl relocate database -d -n ，命令返回成功后表示数据库服务已完成迁移
• 迁移过程中会自动触发 TAF 切换，客户端连接通常可以保持，原节点上的会话会逐步 drain，而不是被强制 kill
• 需要注意目标节点的资源必须充足，可通过 crsctl status resource -t 确认 ora..db 已经在目标节点处于 online 状态
• relocate 完成后，原节点上的 CRS 仍可继续运行，但数据库资源已经释放，此时可进行打补丁、系统重启或其他维护操作，而不会影响线上业务

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

在维护窗口期间，如果恰好存在大事务正在执行，例如批量导入、索引重建或大规模数据处理，一旦空间不足，而 RESUMABLE_TIMEOUT 设置过大（如 3600），就可能导致事务长时间挂起并持续占用锁资源，进而拖慢恢复进度，甚至影响业务切换效率。

• 建议在维护前临时调低该参数：ALTER SYSTEM SET RESUMABLE_TIMEOUT = 300 SCOPE=BOTH;（即 5 分钟超时）
• 对于关键批处理任务，提前检查 DBA_RESUMABLE 视图，确认没有 active 挂起项；若存在，可手动执行 ALTER SESSION DISABLE RESUMABLE 或直接中止相关会话
• 在 RAC 环境中，需要逐个节点执行 ALTER SYSTEM，不能只修改单个 instance，否则参数可能不会在整个集群范围内一致生效
• 维护结束后应恢复原始参数值，避免对日常 DML、批处理或常规业务造成额外影响

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

节点维护后无论是重启服务器还是重启网络服务，最容易被忽视的往往是私网（interconnect）心跳的连通性。即使通过 tnsping 或 sqlplus 访问 VIP 一切正常，也不代表集群节点就一定能顺利加入；如果 CSSD 心跳异常，节点仍然可能被驱逐。

• 使用 oifcfg getif 确认私网接口名称（如 bond0）是否被正确识别，同时检查绑定 IP 是否与 crsctl check cluster -all 的显示结果一致
• 执行 ping -I bond0 -c 5 ，只有丢包率为 0 才能视为达标；单独 ping 公网 VIP 或 hostname 对私网心跳验证没有实际意义
• 检查 /var/log/oracle/crsd/crsd.log 中是否出现 CRS-1601（CSSD 无法加入集群）或 ORA-29702（心跳超时）等错误信息
• 如果私网采用多路径冗余，还应在拔掉一根链路后观察 crsctl stat res -t | grep network 是否依然显示为 ONLINE，否则说明冗余链路并未真正生效