ODP.NET 21.1+版本才正式完全支持Oracle 19c新特性，使用19.x或更早驱动连接19c虽基础功能可用，但易遇ORA-24415或事务异常；推荐NuGet安装Oracle.ManagedDataAccess ≥21.1.0，禁用连接池并启用Validate Connection确保事务可靠性。
确认ODP.NET版本与Oracle 19c兼容性
ODP.NET 21c（即 Oracle.ManagedDataAccess 21.1+）才正式宣称完全支持 Oracle 19c 的新特性（如 Application Continuity、Sharding Metadata）。用 19.x 或更早版本的 Oracle.ManagedDataAccess 连 19c 虽然多数基础功能能跑，但遇到 ORA-24415（Missing username）或事务挂起异常时，大概率是驱动不匹配。
实操建议：
- 在 NuGet 中安装
Oracle.ManagedDataAccess≥21.1.0（不要选Oracle.ManagedDataAccess.Core，它已归档且不更新） - 检查
tnsnames.ora不是必需——推荐用连接字符串直连，避免本地 Oracle Client 环境干扰 - 若用 Windows 身份认证（
OSAUTHENTICATION），需确认数据库端SQLNET.AUTHENTICATION_SERVICES配置，否则会静默降级为用户名密码模式
构造安全连接字符串并启用事务支持
Oracle 19c 默认关闭隐式事务（AutoCommit = false 是客户端行为，不是服务端设置），但连接字符串里漏掉关键参数会导致 OracleTransaction 提交失败或抛 ORA-01086（savepoint 不存在）。
实操建议：
- 必须显式指定
Pooling=false或确保连接池未干扰事务生命周期（长事务慎用连接池） - 添加
Validate Connection=true，防止连接复用时事务上下文残留 - 典型安全连接字符串示例：
"User Id=hr;Password=hr;Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=mydb.example.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCLPDB1)));Pooling=false;Validate Connection=true;"
用 OracleTransaction 正确管理多语句事务
直接调 connection.BeginTransaction() 没问题，但 Oracle 对保存点（savepoint）和自治事务（PRAGMA AUTONOMOUS_TRANSACTION）敏感；若在事务中执行 DDL（如 CREATE TABLE），会隐式提交前序 DML，且无法回滚——这不是 C# 问题，是 Oracle 行为。
实操建议：
- 所有命令（
OracleCommand）必须显式绑定Transaction属性，不能只靠 connection 上下文 - DDL 操作前务必先
transaction.Commit()或改用独立连接 - 嵌套事务不可行，
SaveChanges()类 ORM 模式需手动拆解为单个OracleCommand+ 显式transaction - 示例关键片段：
using var conn = new OracleConnection(connStr); conn.Open(); using var tx = conn.BeginTransaction(); try { using var cmd1 = new OracleCommand("INSERT INTO orders VALUES (:id, :amt)", conn, tx); cmd1.Parameters.Add(":id", OracleDbType.Int32).Value = 1001; cmd1.Parameters.Add(":amt", OracleDbType.Decimal).Value = 299.99m; cmd1.ExecuteNonQuery(); <pre class="brush:php;toolbar:false;">using var cmd2 = new OracleCommand("UPDATE inventory SET qty = qty - 1 WHERE prod_id = 7782", conn, tx); cmd2.ExecuteNonQuery(); tx.Commit(); // 必须显式调用} catch { tx.Rollback(); // 出错时必须 Rollback，否则连接可能卡在事务中 throw; }
处理 Oracle 特有的事务边界陷阱
Oracle 的事务边界比 SQL Server 更严格：游标未关闭、REF CURSOR 输出参数未读取、甚至未消费的 OracleDataReader 都可能导致 ORA-01002: fetch out of sequence 并阻塞后续 Commit()。
实操建议：
- 所有
OracleCommand执行后，若返回结果集，必须完整读取（reader.Read()直到false）或显式reader.Close() - 避免在事务中使用
SELECT ... FOR UPDATE NOWAIT后不立即更新——锁会持续到事务结束，容易引发死锁 - 批量操作慎用
ArrayBindCount：它内部按批提交，破坏事务原子性；如需事务一致性，改用循环单条 + 同一transaction
Oracle 事务真正难的不是写法，而是理解哪些操作会隐式提交、哪些资源没释放会卡住整个事务上下文。尤其当混合 DML 和 PL/SQL 存储过程调用时，得盯着 V$TRANSACTION 和 V$SESSION 视图才能看清实际状态。
