读写分离需明确区分读/写连接来源并强制路由,.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 不保证该视图实时更新
真正难的不是怎么切连接串,而是识别哪些查询可以安全下推到读库、哪些必须保留在写库,以及如何让团队所有开发者遵守这套路由约定。连接字符串只是开关,背后是数据一致性边界的设计决策。











