Oracle事务回滚挂起大概率是DTC（分布式事务协调器）自动介入导致，典型表现为ROLLBACK后线程卡住、无异常日志、连接无响应；需检查连接字符串是否含Enlist=true（默认）、Windows事件日志中MSDTC错误、Oracle视图v$global_transaction中state是否为PREPARED，并通过禁用Enlist=false或正确配置DTC网络权限来解决。
Oracle事务回滚挂起，先看是不是DTC在搅局
如果你的.net应用调用oracle数据库时，执行 rollback 后线程卡住、连接长时间无响应、甚至整个应用线程池耗尽，且错误日志里没有明显异常（比如没抛 oracleexception），那大概率不是sql或pl/sql逻辑问题，而是分布式事务协调器（dtc）在后台“默默锁死”了事务状态。
DTC介入的典型信号是：事务明明没显式调用 TransactionScope 或没跨资源，但 .NET 的 OracleConnection 却被自动提升为 MSDTC 分布式事务——尤其在 Windows Server 环境下，只要连接字符串含 Enlist=true（默认值），且本地存在 DTC 服务，就可能触发。
- 检查应用是否无意中启用了分布式事务：哪怕只连一个 Oracle 数据库，若
System.Transactions.TransactionManager检测到环境满足“潜在分布式条件”（如启用了网络 DTC 访问、COM+ 配置、甚至某些 IIS 应用池标识权限），就会强制升级 - 确认 Oracle 客户端驱动版本：Oracle Data Provider for .NET（ODP.NET）12.1 及之后版本对 DTC 的自动 enlist 行为更激进；旧版（如 11.2）相对保守
- 挂起往往发生在
TransactionScope.Dispose()或显式rollback()调用后，而非 SQL 执行时——说明控制权已交到 DTC 层，但 DTC 无法完成两阶段提交（2PC）的 prepare 阶段
验证DTC是否真被激活：查Windows事件日志和Oracle会话状态
别猜，直接取证。挂起事务的根源必须定位到具体协调者。
在 Windows 服务器上打开事件查看器，筛选 Application 日志，关键词搜索：MSDTC、0x8004d00e（DTC 通信失败）、TransactionManager。常见报错如：The transaction manager has disabled its support for remote/network transactions —— 这说明 DTC 拒绝了协调请求，但 .NET 线程还在等它响应。
同时登录 Oracle，查当前有无疑似 DTC 关联的挂起事务：
SELECT s.sid, s.serial#, s.username, s.machine, t.used_ublk, t.start_time, 'XID:' || t.xidusn || '.' || t.xidslot || '.' || t.xidsqn AS xid FROM v$transaction t JOIN v$session s ON t.ses_addr = s.saddr WHERE t.xidusn > 0 AND s.program LIKE '%DTC%';
如果 s.program 显示 ORACLE.EXE@... (DTC) 或 xid 格式为高位非零（如 XID:7.45.123456），基本可锁定是 DTC 提交/回滚卡在 prepare 或 commit 阶段。
关闭DTC自动注册：修改连接字符串与应用配置
最直接有效的解法，是让 Oracle 连接彻底绕过 DTC。这不是妥协，而是回归设计本意：单数据库事务不该依赖分布式协调器。
- 强制禁用 enlist：在连接字符串末尾添加
Enlist=false，例如：Data Source=ORCL;User Id=scott;Password=tiger;Enlist=false; - 若使用 Entity Framework Core，确保
OracleDbContextOptionsBuilder未启用分布式事务支持；EF6 则检查DbConfiguration中是否注册了OracleProviderServices的 DTC 监听器 - 全局禁用（谨慎）：在
app.config或web.config的<system.transactions>节点下添加：<defaultSettings distributedTransactionManagerName="" />—— 这会让所有TransactionScope默认不尝试升级
注意：改完必须重启应用进程。IIS 应用池回收后，旧连接可能缓存着 DTC 上下文，不重启无效。
真要保留DTC？那就配通它，而不是让它挂起
如果业务确实需要跨 Oracle + SQL Server 或 COM+ 组件的分布式事务，那不能禁用 DTC，而要确保它能正常通信。
- Windows 服务必须运行：
MsDtc服务状态为“正在运行”，启动类型设为“自动（延迟启动）” - 网络访问必须放行：在 DTC 属性 → “安全”页，勾选：
允许远程客户端、允许远程管理、允许入站/出站；取消勾选要求进行认证（开发/测试环境可接受；生产环境需配合域策略） - 防火墙开放端口：DTC 默认使用动态端口，建议在 DTC 属性 → “安全”页底部点击“配置 MSDTC 端口”，固定为
51000-51005范围，并在 Windows 防火墙中放行该端口段 - Oracle 侧验证：执行
SELECT * FROM v$global_transaction;，若state字段长期为PREPARED或RECOVERING，说明 DTC 未完成第二阶段，此时需人工干预：COMMIT FORCE 'xid_string';或ROLLBACK FORCE 'xid_string';
真正棘手的从来不是“怎么配”，而是“谁在用 DTC 却没意识到”。很多老项目在迁移过程中保留了 TransactionScope 包裹单库操作的习惯，结果在新 Windows Server 上因 DTC 策略收紧而集体挂起——这种隐式依赖，比显式报错更难排查。
