节点维护前必须确认TAF真正启用且FAILOVER_MODE嵌套在CONNECT_DATA下，RAC One Node需用relocate而非shutdown，维护前应调小RESUMABLE_TIMEOUT并验证私网心跳连通性。
节点维护前必须确认 TAF 是否真正启用
没配 FAILOVER_MODE 的 RAC 集群，哪怕写了 FAILOVER=ON，维护时也会断连。TAF（Transparent Application Failover）不是可选功能，而是长连接不中断的唯一路径。
-
FAILOVER_MODE必须嵌套在CONNECT_DATA下，写在DESCRIPTION层级会被 Oracle 静默忽略 - 典型有效配置：
(FAILOVER_MODE=(TYPE=session)(METHOD=basic)(RETRIES=3)(DELAY=5)) - 验证方式：连接后查
v$session的failover_type和failover_method字段，非空才表示生效 - JDBC URL 中若用
oracle.jdbc.replay=false或驱动版本过低（如 ojdbc6），可能绕过 TAF，需升级到 ojdbc8+ 并禁用 replay
RAC One Node 场景下 relocate 比 shutdown 更安全
如果用的是 RAC One Node（单实例集群模式），别直接停库——它支持在线 relocate，即把数据库服务从待维护节点平滑迁移到另一节点，全程业务无感知。
- 执行
srvctl relocate database -d <db_name> -n <target_node>，命令返回成功即完成迁移 - 迁移过程会自动触发 TAF 切换，客户端连接保持，旧节点上的会话逐步 drain，不强制 kill
- 注意：目标节点必须资源充足，
crsctl status resource -t要确认ora.<db_name>.db已 online 在目标节点 - relocate 后原节点仍可继续运行 CRS，但数据库资源已释放，可打补丁或重启 OS，不影响业务
维护窗口内避免触发 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 <peer_private_ip>，丢包率为 0 才算达标；仅 ping 公网 VIP 或 hostname 完全无效 - 检查
/var/log/oracle/crsd/crsd.log里是否有CRS-1601（CSSD 无法加入集群）或ORA-29702（心跳超时） - 若用多路径私网，拔掉一根线后必须观察
crsctl stat res -t | grep network是否仍为 ONLINE，否则说明冗余未生效
