oracle.manageddataaccess自2021年起明确移除对system.transactions分布式事务支持，不兼容msdtc/xa，transactionscope中多oracle连接或跨库操作会抛notsupportedexception；替代方案推荐outbox模式实现最终一致性。
oracle数据库在asp.net core中无法直接参与跨资源的分布式事务（如 transactionscope 跨 oracle + sql server），因为 oracle 官方驱动（oracle.manageddataaccess）自 2021 年起已**明确移除对 system.transactions 的分布式事务支持**，且不兼容 msdtc 或 xa 协议。你试图用 transactionscope 包裹多个 oracle 连接或混合 oracle 与其他数据库的操作，会直接抛出 notsupportedexception: distributed transactions are not supported。
为什么 Oracle.ManagedDataAccess 不支持 TransactionScope 分布式事务
Oracle 官方在 ODP.NET Core 文档中明确说明：仅支持本地连接级事务（OracleTransaction），不实现 ITransactionPromoter 接口，因此无法被 TransactionScope 提升为分布式事务。即使你启用了 Windows 上的 MSDTC 或 Linux 上的 dotnet-transaction-manager，也无效。
- Oracle 数据库本身支持 XA（需配置
dbms_xa包和外部事务管理器），但 .NET 客户端驱动未提供 XA 兼容层 -
OracleConnection.Enlist=true在TransactionScope中只会触发“自动登记”，但登记失败时静默降级为本地事务，不报错也不保证一致性 - 多个
OracleConnection实例在同一个TransactionScope下，实际各自提交，无全局原子性
替代方案：用本地事务 + 补偿机制模拟分布式语义
当必须协调 Oracle 和其他资源（如另一 Oracle 库、HTTP API、文件系统）时，放弃强一致性，改用最终一致性模型：
- 在主 Oracle 库中建一张
outbox表（含id,payload,status,created_at），所有“需跨系统生效”的变更先写入此表并提交本地事务 - 启动后台轮询任务（如
IHostedService），扫描status = 'pending'的记录，尝试调用下游服务（如发 MQ、调 HTTP 接口） - 下游成功后，更新该记录
status = 'processed'；失败则重试（带指数退避）或转入死信表 - 若下游是另一个 Oracle 库，可复用同一套 outbox 表 + 同步消费者，避免跨库事务
如果坚持用多 Oracle 连接做“伪分布式”事务
仅限同一 Oracle 实例下的多个 Schema 或不同连接指向同一数据库（非 RAC 多节点）——此时可手动控制事务边界，但风险极高：
- 用同一个
OracleConnection实例执行所有 DML，再统一Commit()—— 这本质仍是本地事务，不是分布式 - 若必须用多个连接，需自行实现两阶段提交逻辑：第一阶段各连接
BeginTransaction()+ 执行 +Prepare()（Oracle 支持OracleTransaction.Prepare()），第二阶段统一Commit()或Rollback()；但Prepare()要求数据库启用分布式事务支持（ALTER SYSTEM SET distributed_transactions = 100），且驱动版本 ≥ 19c，.NET 端仍需绕过TransactionScope - 一旦某个
Prepare()成功而后续Commit()失败，数据库会留下 in-doubt transaction，需 DBA 手动干预（SELECT * FROM DBA_2PC_PENDING）
真正跨 Oracle 实例或跨异构数据源时，不要碰 TransactionScope 和 Oracle 的组合。outbox 模式 + 幂等消费是最可控、可监控、可回溯的路径。最容易被忽略的是：Oracle 驱动的“静默降级”行为，它会让你误以为事务生效了，实则早已各自提交。
