begin distributed transaction 静默失败是因未满足全部前置条件而自动降级为本地事务：需启用 remote proc trans、开启 rpc out、set xact_abort on，且 msdtc 安全配置（允许远程客户端/入站/出站）及端口固定必须到位。
为什么 BEGIN DISTRIBUTED TRANSACTION 总是静默失败
它根本没升级成分布式事务，而是退化为本地事务继续执行——远程操作照常提交，本地回滚也带不动它。这不是语法错，是 SQL Server 的“自动降级”机制在起作用：只有满足全部前置条件时，它才肯把事务交由 MSDTC 管理。
常见现象包括：EXEC [srv_link].db.dbo.sp_name 成功返回、但远程表数据已写入、本地 ROLLBACK 完全无效；错误日志里找不到明显报错，只看到事务提前结束。
关键判断点：
-
sp_configure 'remote proc trans', 1必须已启用（默认为 0） - 链接服务器必须开启
rpc out：EXEC sp_serveroption 'srv_link', 'rpc out', 'true' -
SET XACT_ABORT ON必须出现在BEGIN DISTRIBUTED TRANSACTION之后、任何跨服务器语句之前 - 远程存储过程内部的
BEGIN TRAN/COMMIT对分布式事务无意义——它只是个黑盒调用，不参与两阶段提交
MSDTC 安全配置最容易漏掉的三项
DTC 服务运行着，不代表它能跨机器通信。Windows 默认禁用所有远程 DTC 访问，哪怕防火墙全开、端口全通，只要这三项没勾上，BEGIN DISTRIBUTED TRANSACTION 就会静默失效。
打开 dcomcnfg → 计算机 → 我的电脑 → 分布式事务协调器 → 本地 DTC → 属性 → 安全配置，必须确认以下三项已勾选：
- 允许远程客户端
- 允许入站
- 允许出站
额外注意：
- 若勾选了“要求进行身份验证”，所有参与服务器必须在同一个域内；工作组环境建议直接取消该选项
-
AllowOnlySecureRpcCalls = 0（注册表路径：HKLM:\Software\Microsoft\MSDTC\），否则 RPC 调用会被拒绝 - “允许远程管理”不是必需项，但调试时开启能避免 dtcping 工具被拒
防火墙和端口问题为什么总在重启后重现
DTC 使用 RPC 动态端口（默认 49152–65535），每次服务重启可能分配不同端口。网管放开一个临时端口（比如 55441）后测试通过，但重启 DTC 服务就又断连——这是最典型的“端口漂移”现象。
解决方式不是逐个开动态端口，而是固定 DTC 使用的端口范围：
- 在
dcomcnfg→ 本地 DTC → 属性 → 事务管理器通信 → “在此计算机上使用下列端口”中，填入一段确定范围（如50000-50050） - 防火墙规则必须同时放行：
TCP 135+ 你指定的端口范围（如50000-50050） - 用
dtcping -t验证双向连通性，成功响应是DTC Ping succeeded，不是“timeout”或“access denied”
别信 telnet server 135 通过就万事大吉——它只说明 RPC 端口监听正常，不保证 DTC 实际能协商出可用的动态端口。
链接服务器调用远程存储过程 ≠ 分布式事务参与方
这是最隐蔽也最常被误解的一点：EXEC [srv_link].db.dbo.sp_name 永远不会让远程存储过程里的写操作纳入当前分布式事务上下文。
原因很直接：SQL Server 把这类调用视为“外部过程调用”，只关心返回值（@@ERROR），不追踪其内部事务状态。即使它内部 INSERT 失败，你也只能靠 IF @@ERROR 0 ROLLBACK 手动干预，DTC 不介入。
真正能加入两阶段提交的，只有以下两类语句：
- 四部分命名的 DML：
INSERT INTO [srv_link].db.schema.table ... - 封装为单条语句的
OPENQUERY：INSERT INTO OPENQUERY([srv_link], 'SELECT col FROM db.schema.table') ...
OPENDATASOURCE 和 OPENROWSET 完全不支持事务上下文传递，调用它们的语句永远游离于分布式事务之外。
如果你的业务逻辑必须走远程存储过程，唯一可靠的方式是把它拆解，把核心写操作改用四部分命名法直写目标表——否则所谓“原子性”只是幻觉。
