业务未切走主因是scan监听未接管、vip未漂移或应用未重连，三者占90%以上；需检查crsctl status res -t中scan监听和vip资源是否online、dns轮询是否生效、应用连接串是否真用scan、客户端连接池及jdbc配置是否适配rac故障转移。
业务没切走，不是DG或RAC本身坏了，而是SCAN监听没接管、VIP没漂移、或者应用连接没断开重连——这三类问题占了90%以上。
检查SCAN监听和VIP是否真在线
节点宕机后，SCAN监听必须由存活节点继续提供服务，否则新连接进不来；VIP也得自动漂到另一节点，否则老连接会卡在已下线的IP上。
- 在存活节点执行
crsctl status res -t，重点看ora.LISTENER_SCAN1.lsnr和ora.<node_name>.vip</node_name>是否都为ONLINE - 若
ora.LISTENER_SCAN1.lsnr是OFFLINE或INTERMEDIATE，说明SCAN监听没被集群接管，手工启的lsnrctl start无效 - 用
srvctl config listener确认SCAN监听绑定的IP是否包含当前存活节点的公网IP（不是私网） - 执行
nslookup <scan_name></scan_name>，确认返回的IP列表中不包含宕机节点的VIP
验证应用连接是否真的用了SCAN
很多“连SCAN”的配置实际是假的：应用连接字符串里写的是某个节点VIP，或者DNS解析把SCAN名固定到了一个IP上。
- 查应用连接串，确认是否含
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<scan_name>)(PORT=1521)))</scan_name>—— 不是某节点的VIP或hostname - 在数据库端查
v$session，过滤machine或client_info，看真实来源IP是否来自宕机节点（说明DNS没做轮询或客户端缓存了IP） - 用
tnsping <scan_alias></scan_alias>多次执行，观察返回的IP是否轮换；若始终返回同一个，说明负载均衡失效 - 检查DNS服务器是否开启
round-robin，且TTL设得足够短（建议 ≤ 60秒），避免客户端长期缓存
确认CRS是否完成自动恢复
节点宕机后，Clusterware会在后台尝试拉起服务，但这个过程可能卡住——尤其当OCR/Voting Disk访问异常、CTSS时间不同步或网络资源未就绪时。
- 运行
crsctl check crs，若返回CRS-4638说明HA服务在线；若报CRS-4639，需以root执行crsctl start crs - 检查
crsctl stat res -t | grep -E "(net1|asm|cssd)"，确保ora.net1.network、ora.asm、ora.cssd全部为ONLINE - 若
ora.net1.network是OFFLINE，先crsctl start res ora.net1.network，再等几秒重试其他资源 - 查
$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>，搜索eviction或missed heartbeat，确认是否发生过节点驱逐
别忽略客户端连接池和超时设置
即使服务端已切换成功，应用层仍可能因连接池复用旧连接、TCP保活时间过长而持续卡住。
- Oracle JDBC连接串中必须含
oracle.jdbc.replay=false（12c+默认true，但RAC故障切换时不兼容） - 连接池（如HikariCP、Druid）要启用
testOnBorrow或validationQuery=SELECT 1 FROM DUAL，避免复用失效连接 - TCP层面：检查客户端操作系统
net.ipv4.tcp_keepalive_time，若设为7200秒（2小时），连接卡住会持续很久 - 最直接验证法：从应用服务器
telnet <scan_ip> 1521</scan_ip>，若通但应用连不上，基本锁定在连接池或JDBC驱动配置
真正卡点往往不在数据库侧，而在DNS解析策略、客户端连接池回收逻辑、或JDBC驱动对RAC故障转移的支持程度——这些地方改错一个参数，比重启十次CRS都管用。
