必须显式使用BEGIN DISTRIBUTED TRANSACTION，因SQL Server不会自动升级跨库操作为分布式事务；需同时满足rpc out=true、remote proc transaction promotion=true、MSDTC就绪且安全配置到位，缺一即静默降级为本地事务。
SQL Server 存储过程中必须显式写 BEGIN DISTRIBUTED TRANSACTION
触发器或存储过程里直接用四段式语句（如 INSERT INTO [RemoteDB].[dbo].[T]）不会自动升级事务，而是静默失败或卡死在 The transaction manager has disabled its support for remote/network transactions。根本原因是 SQL Server 默认只在本地事务上下文中运行，跨库操作必须人工声明分布式事务边界。
实操要点：
-
BEGIN DISTRIBUTED TRANSACTION必须出现在所有跨库 DML 之前，且不能嵌套在BEGIN TRY外层——否则异常时无法回滚远程端 - 调用远程存储过程（如
EXEC [LinkedSrv].[TargetDB].[dbo].[usp_sync]）前，必须已开启rpc out：运行EXEC sp_serveroption 'LinkedSrv', 'rpc out', 'true' - 同时启用
remote proc transaction promotion：否则即使写了BEGIN DISTRIBUTED TRANSACTION，SQL Server 仍拒绝协调 - 本地和远程数据库必须使用完全一致的字段类型，例如
datetime2(7)→datetime2(7)，nvarchar(100)→nvarchar(100)；任何隐式转换都可能导致NOT MATCHED判断失效
链接服务器配置是前置硬门槛，不是可选项
没配好链接服务器，后续所有代码都会报错或丢数据。它不是“连得上就行”，而是一组相互依赖的开关组合。
必须逐项确认：
-
rpc out = true：否则EXEC [LinkedSrv]...直接被拦截，错误是Msg 7411, Level 16, State 1 -
remote proc transaction promotion = true：否则BEGIN DISTRIBUTED TRANSACTION形同虚设，远程操作仍在本地事务中执行 - 目标服务器 MSDTC 必须启用网络访问（开发机可临时勾选“不支持事务”，但生产环境必须开防火墙 + 配置安全通信）
- 链接服务器登录映射需明确指定账号密码，不能依赖
self mapping，否则权限不足导致写入静默失败
别在存储过程里拼接动态 SQL 做跨库写入
用 OPENQUERY 或 OPENDATASOURCE 封装跨库 INSERT 看似简单，实际埋雷密集：参数无法绑定、@@ROWCOUNT 失效、SQL 注入风险高、无法捕获远程端具体错误码。
更稳的做法：
- 目标库单独建带
TRY...CATCH的存储过程（如usp_sync_upsert），内部处理INSERT/UPDATE并返回@ret INT状态码 - 源库存储过程只负责传参调用：
EXEC [LinkedSrv].[TargetDB].[dbo].[usp_sync_upsert] @id, @name, @ts - 调用后立刻检查
IF @@ERROR 0 OR @ret 0，决定是否ROLLBACK或记录失败日志 - 跳过
IDENTITY列、计算列、默认约束字段；如需写入IDENTITY，远程过程内先SET IDENTITY_INSERT ON
Azure SQL 托管实例可用原生 T-SQL 分布式事务，但 Azure SQL 数据库不行
如果你用的是 Azure SQL 托管实例，可以直接在存储过程中写 BEGIN DISTRIBUTED TRANSACTION + 跨库 DML，无需 MSDTC 配置——事务协调已集成进服务。但 Azure SQL 数据库不支持服务器端分布式事务，哪怕你用 EXEC sys.sp_getapplock 也绕不过这个限制。
关键区别：
- Azure SQL 托管实例：支持
BEGIN DISTRIBUTED TRANSACTION、支持链接服务器 + 远程存储过程调用、支持sp_serveroption配置 - Azure SQL 数据库：仅支持客户端弹性事务（
Microsoft.Azure.SqlDatabase.ElasticScale.Transaction），必须用 .NET 的TransactionScope在应用层启动，T-SQL 层无对应语法 - 两者之间不互通：不能让 Azure SQL 数据库作为协调者去管托管实例的分支事务
跨云或混合部署时，最容易忽略的是事务协调者的归属——不是“谁发起谁协调”，而是“由哪个平台能力决定能否协调”。写在存储过程里的分布式事务，永远受限于它所运行的 SQL Server 实例类型。
