在什么情况下,来自C应用程序的MSDTC事务的SQL复制会部分(且无提示地)失败

我们有一个特别奇怪的问题,让我来说明一下。 找到解决方案,见下文

我们有三个SQL Server 2005数据库,为便于讨论,称为: 阿尔法 , 贝塔 和 伽马 .

这些数据库之间定义了复制关系,如下所示:

这三个数据库都有一个名为“anexample”的表,具有相同的模式。复制设置为 阿尔法 是提供程序,其他两个数据库是订阅服务器。

1. 使用msdtc事务(由transactionscope处理)的c.net 3.5应用程序同时读取和写入数据库:alpha和beta。
2. 此事务中的表“anexample”仅在alpha上更新。
3. msdtc事务已成功提交。
4. “anexample”表可能在中更新 阿尔法 而这一变化立即被复制到 伽马
5. 上未发生更改 贝塔 (探查器确认数据库上没有发生任何活动),SQL日志或事件日志中也没有出现任何错误
6. 在management studio中使用相同凭据更新“anexample”的查询重新运行成功(复制到 贝塔 发生)
7. 运行对上另一个表的msdtc事务写入 贝塔 ,然后使用主应用程序dal、连接字符串和配置对alpha的“anexample”表进行完全相同的写入操作也完全成功(复制到 贝塔 发生)

这使我们相信主应用程序中发生了一些变化,而这些变化并不是孤立地发生的。

可能的线索/红鲱鱼

在我们成功的测试和主应用程序使用的实际查询之间,唯一的区别是隔离级别已经有所改变。在成功的查询中,它被设置为事务隔离级别read committed only,而在失败的场景中它被设置为serializable(尽管没有显式调用来更改代码库或存储过程中的隔离级别)。

我们确实觉得这有点像在management studio中使用这种隔离级别再次成功地运行查询而没有问题。但事实上,这可能是我们尚未发现的另一个问题的征兆,这是不同的观点。

为了完整起见,下面是无法复制到beta版(但对gamma版)的查询的设置。

-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level *serializable*

有点像个头巾。