读写分离需明确区分读/写连接来源并强制路由，.NET无内置支持，须用独立OracleConnectionStringBuilder实例、禁用读库连接池，读操作推荐Dapper+连接工厂，强一致场景必须走写库查询。
读写分离不是靠单个 OracleConnectionStringBuilder 能搞定的
直接在代码里用一个连接字符串来回切换读/写，本质是伪分离——它不解决连接复用、事务一致性、主从延迟感知等问题。真正可行的路径是：**明确区分读操作与写操作的连接来源，并在数据访问层强制路由**。.net 中没有内置 oracle 读写分离支持，必须自己控制连接字符串的分发逻辑。
常见错误现象：ORA-01017: invalid username/password 或 ORA-12154: TNS could not resolve the connect identifier，往往是因为读库连接串里误配了写库的 service_name，或未在 tnsnames.ora 中正确定义两个别名。
- 读连接串和写连接串必须是两个独立的
OracleConnectionStringBuilder实例，不能共享同一对象后修改DataSource - 推荐使用
Oracle.ManagedDataAccess（非 ODP.NET Unmanaged），避免客户端 DLL 版本冲突 - 不要在 EF Core 的
DbContext.OnConfiguring中动态切换连接串——这会导致连接池混乱、事务跨库失败
用 IDbConnection 工厂 + 枚举路由实现最简读写分离
不依赖框架抽象，直接在仓储方法中显式指定连接类型，是最可控、最容易调试的方式。核心是封装一个连接工厂，根据 ConnectionRole.Read 或 ConnectionRole.Write 返回对应连接串构建的 OracleConnection。
示例关键代码：
public enum ConnectionRole { Read, Write }
<p>public class OracleConnectionFactory
{
private readonly string _readConnString;
private readonly string _writeConnString;</p><pre class="brush:php;toolbar:false;">public OracleConnectionFactory(string readConn, string writeConn)
{
_readConnString = readConn;
_writeConnString = writeConn;
}
public OracleConnection Create(ConnectionRole role) =>
new(role == ConnectionRole.Read ? _readConnString : _writeConnString);}
- 读库连接串中的
DataSource应指向只读副本的 TNS 别名（如ORCL_READ），写库指向主库（如ORCL_WRITE） - 务必关闭读库连接串的
Pooling=true（或设为false）——若读写共用连接池，可能因连接复用导致写操作意外落到读库 - 如果用 Dapper，调用时直接传入工厂返回的连接：
conn.Query<user>("SELECT * FROM users", ...)</user>
EF Core 中绕过 DbContext 生命周期做读写路由
EF Core 默认把整个 DbContext 绑定到一个连接，无法原生支持运行时切换。强行在 OnConfiguring 里根据当前方法名判断读写，会破坏上下文生命周期管理，且无法处理跨方法事务。
更稳妥的做法是：**只让 DbContext 承担写职责，读操作全部走原生 OracleConnection + Dapper**。
- 写操作继续用
DbContext.SaveChanges()，连接串固定为写库 - 读操作（尤其是报表、列表页）全部剥离出
DbContext，由OracleConnectionFactory提供读连接，用 Dapper 执行 SQL 或映射 - 若必须用 EF Core 查询读库，可新建轻量级
DbContext子类，构造函数强制注入读连接串，并禁用变更跟踪：context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;
主从延迟下，刚写入就读不到？OracleConnection 不自动感知同步状态
Oracle Data Guard 的物理备库默认是“最大性能”模式，主库提交后，从库应用日志存在毫秒到秒级延迟。代码层没有任何机制能自动等待同步完成——这不是 .NET 的问题，而是 Oracle 架构决定的。
这意味着：如果你执行完 INSERT 立即用读连接查同一条记录，大概率查不到。这是读写分离的固有代价。
- 对强一致性要求高的场景（如用户注册后立即跳转个人页），必须走写库查询，哪怕慢一点
- 可在业务层加简单重试（最多 1–2 次，间隔 100ms），但不要用
Thread.Sleep，改用await Task.Delay - 不要试图通过
V$DATAGUARD_STATS在每次读前查延迟——开销大、不可靠，且 Oracle 不保证该视图实时更新
真正难的不是怎么切连接串，而是识别哪些查询可以安全下推到读库、哪些必须保留在写库，以及如何让团队所有开发者遵守这套路由约定。连接字符串只是开关，背后是数据一致性边界的设计决策。
