是的，oracleconnection在.net 6中默认enlist=true且dtc启用时会自动登记到msdtc，可能导致rollback挂起；解决方式为连接字符串加;enlist=false或正确配置dtc网络权限。
OracleConnection 默认会自动 enlist 到 MSDTC？
是的，OracleConnection 在 .NET 6 中只要连接字符串含 Enlist=true（默认行为），且 Windows 系统启用了 DTC 服务，就会尝试自动登记到分布式事务协调器。这不是你显式调用 TransactionScope 才触发的——哪怕只连一个 Oracle 数据库，也可能被升级为分布式事务。
典型症状：执行 rollback() 后线程卡住、无异常、连接池耗尽；查 Windows 事件日志能看到 MSDTC 错误码 0x8004d00e；查 Oracle 视图 v$global_transaction 可见 state = 'PREPARED'。
- ODP.NET 12.1+ 版本对自动 enlist 更激进，旧版（如 11.2）相对保守
- 禁用方式很简单：在连接字符串末尾加
;Enlist=false - 若必须用分布式事务（如跨 Oracle + SQL Server），则需手动配置 DTC 网络访问权限、防火墙规则，并确保 Oracle 客户端与 DTC 版本兼容
不用 MSDTC，怎么在微服务间保证 Oracle 数据一致性？
微服务架构下，强一致的两阶段提交（2PC）基本不可行。Oracle 本地事务只管单库，跨服务必须靠最终一致性方案。
推荐路径：用 Seata 的 AT 模式 + Oracle。它不依赖 DTC，而是通过代理数据源拦截 SQL，在业务提交前自动生成 undo_log 表记录反向操作，失败时回滚到快照状态。
- Seata AT 要求 Oracle 表必须有主键，且
undo_log表需手动建在每个业务库中（不是全局一张） - ODP.NET 驱动需使用
Oracle.ManagedDataAccess.Core，不能混用旧版Oracle.DataAccess - 注意隔离级别：AT 模式默认读已提交（READ COMMITTED），不支持可重复读；高并发场景下可能遇到脏写，需配合应用层乐观锁或唯一约束兜底
Dapper + Oracle 在 .NET 6 中如何避免事务意外升级？
很多人以为 Dapper 是“轻量 ORM”，不会碰事务逻辑——但它完全复用 ADO.NET 的底层连接行为。只要 IDbConnection 实例被传入 TransactionScope 或由框架自动管理（如 ASP.NET Core 的 scoped service），就可能触发 enlist。
实操建议：
- 注册
IDbConnection时明确控制生命周期：用AddTransient而非AddScoped，避免连接被跨请求复用并卷入隐式事务 - 手动开启事务时，始终用
connection.BeginTransaction(IsolationLevel.ReadCommitted)，而非依赖TransactionScope - 检查 DI 容器里是否无意注入了
TransactionScope或ITransactionManager类型的服务（尤其在引入第三方事务中间件时）
Oracle 自治事务（PRAGMA AUTONOMOUS_TRANSACTION）能用在微服务里吗？
不能。自治事务是 PL/SQL 层级的特性，只在存储过程中生效，且与外部事务完全隔离——它无法跨服务、无法参与 Seata 或 Saga 流程，更不能被 .NET 应用感知或协调。
常见误用：想用自治事务记录日志或审计，结果导致主事务回滚后，日志仍被提交，破坏业务语义的一致性边界。
- 替代方案：把日志写入消息队列（如 RabbitMQ/Kafka），由独立消费者落库；或使用 Oracle 的
DBMS_ALERT+ 异步作业，但需额外运维成本 - 自治事务在微服务中唯一合理用途，是极少数需要“绝对不被主事务影响”的内部维护逻辑（如清理临时表），且必须确保该逻辑与业务流程无因果关系
最易被忽略的点：Oracle 的 UNDO_RETENTION 设置过短，会导致 Seata 的 AT 模式回滚时找不到快照，报 Could not find branch record；而 DTC 挂起问题往往不是代码写错，而是 Windows 服务器上 DTC 的“网络访问”开关根本没打开——这两处都没日志，得去 Oracle 参数和 DTC 控制面板里手动确认。
