MSDTC禁用时，如何避免事务中修改存储过程触发分布式事务错误？

你的问题根源在于Serializable隔离级别的特性：当事务中包含跨链接服务器的操作时，SQL Server会自动尝试启动分布式事务（依赖MSDTC），但Azure托管实例默认禁用了MSDTC，因此触发了这个错误。而READ COMMITTED隔离级别不会强制要求分布式事务，所以不会报错，但你的部署工具SQL Compare无法修改隔离级别设置，那可以试试以下几种方案：

1. 在存储过程内部覆盖隔离级别 #

既然外层事务的Serializable是部署工具强制的，那我们可以在存储过程内部显式设置READ COMMITTED隔离级别，覆盖外层的设置。这样当存储过程执行时，会使用较低的隔离级别访问链接服务器，避免触发分布式事务。修改后的存储过程代码如下：

alter procedure abc as 
begin
    -- 临时覆盖隔离级别，仅在存储过程执行期间生效
    SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
    select top 10 * from database2.dbname.dbo.dbtable 
end

这个方法的好处是不需要修改外层的部署事务逻辑，只调整存储过程内部代码即可，而且隔离级别的修改不会影响外层事务的其他操作。

2. 使用OPENQUERY替代直接链接服务器查询 #

OPENQUERY可以直接在远程服务器上执行查询，返回结果到本地，这种方式在Serializable隔离级别下通常不会触发分布式事务（因为查询是在远程独立执行，本地只接收结果）。你可以把存储过程里的查询改成：

alter procedure abc as 
begin
    select * from OPENQUERY(database2, 'select top 10 * from dbname.dbo.dbtable')
end

需要注意的是，OPENQUERY的语法要求远程查询是字符串形式，若后续需要参数化查询，可能需要动态拼接语句，但你的例子里是固定的top 10查询，刚好适用。

3. 调整部署脚本结构，拆分事务 #

如果上面两种方法都不适用，你可以考虑把涉及链接服务器的存储过程修改步骤，从外层的Serializable事务中拆分出来单独执行。虽然你希望整个部署在一个事务里，但对于依赖远程资源的操作，单独执行可以避免分布式事务的问题。比如：

-- 先执行Serializable事务里的其他部署步骤
SET TRANSACTION ISOLATION LEVEL Serializable 
go 
begin transaction 
go 
-- 这里放其他不需要访问链接服务器的部署操作，比如表结构修改、其他存储过程等
commit transaction
go

-- 单独修改涉及链接服务器的存储过程，使用READ COMMITTED隔离级别
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
go
begin transaction
go
alter procedure abc as 
begin 
select top 10 * from database2.dbname.dbo.dbtable 
end 
commit transaction

当然，这样会失去这部分操作的原子性，但如果这个存储过程的修改是独立的，不会影响其他部署步骤的一致性，这个方案是可行的。

4. 启用Azure托管实例的MSDTC（如果环境允许） #

如果你的Azure环境支持（比如托管实例在虚拟网络中，且配置了MSDTC的相关参数），可以尝试启用MSDTC。不过这个操作需要一定的权限和网络配置，而且并非所有场景都适用。具体步骤是在Azure门户中找到你的托管实例，进入"配置"页面，启用MSDTC，并配置对应的事务管理器名称和端口等。但这个方案的复杂度较高，需要评估环境是否允许。

总结来说，最推荐的是方案1和方案2，不需要修改部署工具的配置，只调整存储过程代码即可解决问题。

内容的提问来源于stack exchange，提问作者Marc L. Allen