ODP.NET通过连接字符串中指定Proxy User Id（及Proxy Password）启用代理身份验证，主用户须预先授权；Proxy User Id不同则视为独立连接池，易致池膨胀；验证需执行SELECT SYS_CONTEXT('USERENV','PROXY_USER') FROM DUAL。
ODP.NET 连接字符串里怎么启用代理身份验证
odp.net 支持 oracle 的 proxy 身份验证，但不是靠单独开关控制，而是通过连接字符串中显式指定 proxy user id 和 proxy password（如果需要），同时主用户必须已授权代理权限。关键点是：主连接用户（如 app_admin）需提前执行 alter user app_user grant connect through app_admin，否则连接时会报 ora-01017: invalid username/password 或更隐蔽的 ora-01928: proxy not granted to app_admin。
实操建议：
- 连接字符串中必须包含
User Id（主用户）、Proxy User Id（被代理用户），两者不能相同 - 若被代理用户无密码（如外部认证账户），可省略
Proxy Password，但需确保 Oracle 端配置了SEC_CASE_SENSITIVE_LOGON=FALSE或对应大小写策略 - 不要在连接字符串里写
Pooling=true后再手动调用ClearPool()—— 代理上下文属于连接级状态，池中连接复用时可能携带前一个代理用户的会话残留
连接池是否自动隔离不同代理用户的连接
不隔离。ODP.NET 默认连接池把所有带相同连接字符串的连接视为等价，而 Proxy User Id 是连接字符串的一部分，所以 User Id=app_admin;Proxy User Id=user_a; 和 User Id=app_admin;Proxy User Id=user_b; 被视为两个完全不同的连接池。这意味着每个代理组合都会独占一套池，容易造成池膨胀、连接数超标。
实操建议：
- 避免为每个终端用户动态拼接
Proxy User Id并开启连接池 —— 尤其在 Web 应用中，用户量大时会导致数百个独立小池，DBA 监控会看到大量INACTIVE连接却无法复用 - 如需多代理场景，建议复用固定的一组“代理网关用户”，例如统一用
Proxy User Id=web_proxy，再由应用层在首次执行 SQL 前调用ALTER SESSION SET CURRENT_SCHEMA = user_a切换逻辑 schema - 检查
Max Pool Size是否被无意设得过高（默认是 100），配合代理粒度要同步调低，比如设为20
如何验证当前连接实际使用的代理身份
ODP.NET 不提供直接 API 返回当前生效的代理用户，得靠 SQL 查询确认。最可靠方式是执行 SELECT SYS_CONTEXT('USERENV', 'PROXY_USER') FROM DUAL，返回值为空说明未走代理，返回用户名则表示代理生效；也可查 SYS_CONTEXT('USERENV', 'SESSION_USER') 看主连接用户，对比确认切换是否成功。
实操建议：
- 在打开连接后、执行业务 SQL 前加一段诊断查询，记录日志，尤其上线初期用于排查
ORA-06502类权限错误是否源于代理未生效 - 注意
SYS_CONTEXT是会话级函数，不能在连接池归还后还去查 —— 归还即断开，上下文丢失 - 如果应用使用 Entity Framework Core + ODP.NET，需确保
DbContext没有跨连接复用，否则可能在非代理连接上执行了本该代理的语句
为什么调用 OracleConnection.ClearPool() 后代理连接仍不释放
因为 ClearPool() 只清空与指定连接对象**同连接字符串**的池，而代理连接的字符串含 Proxy User Id，与普通连接不同。如果你拿一个不含 Proxy User Id 的连接对象去调 ClearPool()，它对代理池完全无效。
实操建议：
- 要清理特定代理连接池，必须用一个具有相同完整连接字符串（含
User Id、Proxy User Id、甚至Connection Timeout）的连接对象来调用ClearPool() - 更稳妥的做法是调用静态方法
OracleConnection.ClearAllPools()，但它会影响所有池，生产环境慎用 - 真正需要强制释放的场景，往往是测试或故障恢复，此时建议直接关闭所有
OracleConnection实例并置为null，再等 GC 或显式调Dispose()，比依赖池清理更可控
代理身份验证的连接池行为和常规连接有本质差异，最容易被忽略的是连接字符串的“等价性”判断 —— 看似只差一个参数，背后就是完全独立的池实例。
