BEGIN DISTRIBUTED TRANSACTION 常静默失败，因SQL Server仅在满足特定条件时才将本地事务升级为分布式事务：需启用remote proc trans、链接服务器开启rpc out、MS DTC服务运行且安全配置正确（允许远程客户端/入站/出站）、防火墙放行、SET XACT_ABORT ON。
SQL Server 存储过程中无法直接用 BEGIN DISTRIBUTED TRANSACTION 跨服务器调用远程存储过程并保证原子性，除非所有参与节点都已注册到同一 MS DTC 实例且网络、安全、配置全部就绪——现实中 70% 的失败源于 DTC 配置遗漏或权限不匹配。
为什么 BEGIN DISTRIBUTED TRANSACTION 常常静默失败
它不报错，但事务实际没升级成分布式，本地事务提交后远程操作仍独立执行。根本原因是：SQL Server 只在满足特定条件时才自动将本地事务“提升”为分布式事务。
- 远程存储过程调用（
EXEC server.db.dbo.sp_name）必须发生在已开启的本地事务内，且sp_configure 'remote proc trans', 1已启用 - 链接服务器（
sp_addlinkedserver）必须开启rpc out选项：EXEC sp_serveroption 'srv_link', 'rpc out', 'true' - MS DTC 服务必须在本地和远程 SQL Server 所在机器上都运行，且防火墙放行端口 135 + 动态 RPC 端口
-
SET XACT_ABORT ON必须显式设置，否则错误发生时仅回滚当前语句，DTC 不介入
MS DTC 安全配置最容易漏掉的三项
DTC 默认拒绝跨机通信。即使服务在运行，BEGIN DISTRIBUTED TRANSACTION 也会降级为本地事务。
- 在“组件服务 → 计算机 → 我的电脑 → 属性 → MSDTC → 安全配置”中，必须勾选：
允许远程客户端、允许远程管理、允许入站/出站 - 若启用了“要求进行身份验证”，则所有参与服务器需在同一个域内，或手动配置 DTC 证书信任；工作组环境建议关闭该选项
- Windows 防火墙需放行
Distributed Transaction Coordinator规则（不止是端口，规则名要对）
链接服务器调用远程存储过程的事务行为边界
远程存储过程内部的 BEGIN TRAN / COMMIT 对本地分布式事务无影响——它只是被当作一个“原子操作”执行。真正纳入两阶段提交的，只有你本地显式发起的跨库语句（如 INSERT INTO srv_link.db.schema.table）。
- 若远程存储过程含写操作，它自身会开启独立事务，成功与否只返回状态码（
@@ERROR），不会触发 DTC 回滚 - 想让它参与分布式事务，必须把它的逻辑拆出来，改用四部分命名法直写表（
srv_link.db.schema.table），或用OPENQUERY封装为单条语句 -
OPENDATASOURCE和OPENROWSET不支持事务上下文传递，调用它们的语句永远无法加入分布式事务
调试分布式事务卡在 prepared 状态的方法
DTC 事务一旦进入 prepared 状态却未 commit 或 rollback，就是悬挂事务，可能锁住资源数小时。
- 查悬挂事务：
SELECT * FROM sys.dm_tran_active_transactions WHERE transaction_state = 2（2 表示 prepared） - 强制清理（仅测试环境）：
EXEC sp_repldone不适用；正确做法是用dtcping工具确认双向连通性，再用MSDTC控制台查看“正在准备”的事务列表 - 日志定位点：SQL Server 错误日志里搜
DTC和XACT，关键线索常在 “The transaction has been rolled back because the transaction manager is unavailable” 这类提示之后
真正的难点不在语法，而在 DTC 是 Windows 系统级服务——它不读取 SQL Server 配置，也不受 T-SQL 权限控制。哪怕你把存储过程写得再完美，只要其中一台机器的 DTC 没开“允许入站”，整个事务就降级为本地执行，而你很难从错误信息里看出来。
