Oracle 23ai RAC高可用重构聚焦故障感知前置化与恢复原子化：启用INSTANCE_UNREACHABLE/FAN事件、配置ASM Flex修复窗口、QUIC心跳替代UDP，三者协同生效。
Oracle 23ai 的 RAC 集群在高可用性上不是简单延续旧版本逻辑，而是围绕「故障感知前置化」和「恢复动作原子化」做了关键重构。如果你还在用 crsctl stop crs 模拟节点宕机来验证切换时间，那已经落后于 23ai 的真实能力边界了。
23ai 新增的 FAN 事件类型必须显式启用
Oracle 23ai 在 DBMS_SERVER_ALERT 和 FAN 体系中新增了 INSTANCE_UNREACHABLE 和 CLUSTER_RESOURCE_OFFLINE 两类事件，它们比传统 INSTANCE_DOWN 提前 1.8–3.2 秒触发，但默认不激活。
不启用会导致应用层无法提前切断连接，仍会经历完整 TCP 超时（通常 60–120 秒）。
你需要手动执行：
EXEC DBMS_SERVER_ALERT.SET_THRESHOLD('INSTANCE_UNREACHABLE', 'ENABLED');
同时确保客户端使用支持该事件的 JDBC 驱动（ojdbc11-23.5.0.0 及以上），否则即使数据库发出了事件，驱动也忽略。
ASM Flex Diskgroup 的自动修复窗口可配置
23ai 中 ASM 对磁盘组损坏的响应不再是“立即驱逐+人工干预”，而是引入了 REPAIR_TIMER 参数：
- 默认值是 300 秒（5 分钟），即磁盘离线后等待 5 分钟再启动修复；
- 若共享存储存在短暂抖动（如 SAN 链路瞬断），这个窗口能避免误判导致的不必要的 ASM 重平衡；
- 但若你用的是全闪存 NVMe 存储且网络极其稳定，可安全设为 60，加速故障收敛。
修改方式：
ALTER DISKGROUP DATA SET ATTRIBUTE 'repair_timer' = '60';注意：
repair_timer 仅对 FLEX 类型磁盘组生效，EXTERNAl 或 NORMAL 不识别该属性。
集群心跳机制从 UDP 升级为 QUIC 协议
23ai 的 Oracle Clusterware 默认启用基于 QUIC 的心跳通道（端口 6200），替代传统 UDP 心跳（端口 12590）。
这不是后台静默升级——它直接影响脑裂判断精度：
- QUIC 心跳自带加密与连接状态跟踪，能区分“网络丢包”和“节点死亡”；
- 旧版 UDP 心跳在高丢包率下容易误判为节点失效，触发不必要的 reboot；
- 但若你的防火墙策略未放行 UDP/6200，或内核模块 quic_kmod 未加载，集群将回退到 UDP 模式，且日志里只报 WARNING: QUIC heartbeat disabled，不报错。
验证是否生效：
crsctl stat res -t | grep -i quic应看到类似
ora.cluster_quic.type ONLINE 的输出。
真正难的不是知道这些特性，而是理解它们如何相互咬合：比如 QUIC 心跳缩短故障检测时间，INSTANCE_UNREACHABLE 事件让应用立刻响应，而 repair_timer 控制底层存储修复节奏——三者缺一，高可用链条就断在某个环节。实际部署时，最容易被跳过的其实是客户端驱动升级和防火墙规则更新，这两处没跟上，前面所有配置都白搭。
