根本原因是Oracle RAC中SCN默认非实时同步，MAX_COMMIT_PROPAGATION_DELAY=700（即7秒内延迟）导致跨实例读写时出现读一致性窗口：A实例提交后，B实例本地SCN未及时更新，查询返回旧快照，属性能权衡而非bug。
根本原因不是 rac 切换本身，而是应用层连接和事务行为没适配 rac 的 scn 传播机制——尤其在跨实例读写时，max_commit_propagation_delay 参数决定了“刚提交的数据多久才能被另一节点看到”。
为什么切换后立刻查不到新数据？
Oracle RAC 中，每个实例维护本地 SCN（系统变更号），提交后 SCN 并非瞬时同步到所有节点。默认 MAX_COMMIT_PROPAGATION_DELAY=700（毫秒），意味着最多等待 700ms 才完成 SCN 全局广播。如果 Web Server 连 A 实例提交，Java APP 立刻连 B 实例查，而 B 的本地 SCN 还没更新，就会返回旧快照——这不是 bug，是 Oracle 为性能做的权衡。
- 现象典型：A 提交后，B 查询返回空或旧值，用 SQL*Plus 或工具查却有数据（工具可能连的是 A）
- 错误日志里不会报错，
V$TRANSACTION和V$SESSION也无异常，纯属读一致性行为 - 该延迟只影响“已提交但未广播完成”的极短窗口，不破坏事务 ACID
Managed 驱动（Oracle.ManagedDataAccess）会让问题更隐蔽
因为它是纯托管驱动，不走 OCI，无法利用 RAC 的 TAF（Transparent Application Failover）或 FCF（Fast Connection Failover）自动重路由连接。一旦主实例宕机、连接池中残留的旧连接仍指向已下线节点，或者连接未启用 LOAD_BALANCE=true 和 FAILOVER_MODE，就可能卡在无效连接上，加剧查询不一致感。
- 必须显式配置连接字符串：
LOAD_BALANCE=true;FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=3)(DELAY=1) - 不要依赖
tnsnames.ora；硬编码 SCAN 地址 + SERVICE_NAME 更可控，例如：(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=my-scan)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=myrac))) - 若用 Entity Framework，确保
DbContext生命周期短（每次请求新建），避免跨请求复用连接
哪些参数改了能缓解，但不能根除？
把 MAX_COMMIT_PROPAGATION_DELAY 设为 0 可强制采用 Broadcast on Commit 模式，让 SCN 同步变为同步阻塞——提交操作会等所有实例确认后才返回。但这会显著拖慢高并发 OLTP 场景的吞吐量，且要求所有 RAC 实例该参数值完全一致。
- 设为 0 后，
LGWR必须向每个活动实例发 SCN 更新消息，网络延迟或节点负载高时，提交延迟可能从毫秒级升至百毫秒级 - 仅适用于对强一致性要求极高、且写入频率低的场景（如金融批处理）
- 修改需重启所有实例：
ALTER SYSTEM SET MAX_COMMIT_PROPAGATION_DELAY=0 SCOPE=BOTH SID='*';
真正容易被忽略的点是：RAC 数据不一致从来不是“数据库坏了”，而是应用没声明自己的读一致性需求。要不要等 SCN 同步完再查，该由业务逻辑决定——比如关键状态变更后加一次 SELECT FOR UPDATE 或主动 SLEEP(100) 等待，比硬调数据库参数更轻量、更可控。
