不能直接实现跨 Oracle 与 SQL Server 的分布式事务，因 Oracle.ManagedDataAccess 自2021年起移除对 System.Transactions 分布式事务支持，且不实现 ITransactionPromoter 接口，无法参与两阶段提交，导致 TransactionScope 必然失败。
不能直接实现跨 Oracle 与 SQL Server 的分布式事务。 Oracle.ManagedDataAccess 自 2021 年起已移除对 System.Transactions 分布式事务的支持，调用 TransactionScope 包裹两个不同数据库连接时，会直接抛出 NotSupportedException: Distributed transactions are not supported。
为什么 TransactionScope + Oracle + SQL Server 必然失败
Oracle 官方驱动（Oracle.ManagedDataAccess）不实现 ITransactionPromoter 接口，因此无法参与两阶段提交（2PC）。即使你：启用了 Windows MSDTC、配置了防火墙端口、设置了 Enlist=true、甚至在 Linux 上部署了 dotnet-transaction-manager，都无效。SQL Server 连接可能成功登记进 DTC，但 Oracle 连接只会静默降级为本地事务——结果是：SQL Server 提交了，Oracle 也提交了，但二者无全局原子性，数据不一致已发生，且无报错提示。
常见误操作与静默陷阱
这些做法看似合理，实则危险：
-
TransactionScope中先开OracleConnection再开SqlConnection→ Oracle 连接自动登记失败，后续 SQL Server 事务独立提交 - 在 Oracle 连接字符串中加
Enlist=true→ 不报错，但实际未登记，只是本地事务 - 用同一
TransactionScope调用 Oracle 存储过程 + SQL Server 存储过程 → Oracle 端完全不受事务上下文控制 - 试图启用 Oracle 的
dbms_xa包并手动调 XA 接口 → .NET 驱动未暴露 XA API，不可行
可行替代方案：Outbox 模式（推荐）
放弃强一致性，在主库（建议选 SQL Server 或 Oracle 中更稳定/易监控的那个）建 outbox 表，把“需同步到另一库”的操作序列化为事件记录，再由后台消费者异步投递：
- 表结构至少含：
Id（PK）、EventType（如OrderCreated）、Payload（JSON）、Status（pending/processed/failed）、CreatedAt - 业务逻辑中：在本地事务内写业务表 + 插入一条
outbox记录，一起Commit() - 后台轮询（如
IHostedService）：查Status = 'pending'，尝试执行目标操作（如 INSERT INTO [OracleLink]...），成功则更新Status = 'processed'；失败则重试或转入死信 - 若下游是 Oracle，可用
OPENQUERY或直连 JDBC（通过 .NET 调用外部工具）执行，避免反向依赖
最后提醒一个关键细节
很多人以为“只要两个数据库都支持 XA 就能协调”，但问题不在数据库端——Oracle 和 SQL Server 各自的 XA 实现互不兼容，且 .NET 生态中没有任何主流驱动能桥接二者。真正落地时，outbox 表的幂等写入、消费者去重、状态机回溯、死信人工干预，这些环节比事务语法本身更消耗工程精力。别低估补偿逻辑的复杂度，它不是“加个重试”就能解决的事。
