0

我们有一个特别奇怪的问题；让我设置场景。找到的解决方案见下文

我们有三个 SQL Server 2005 数据库，为了论证，我们称之为：Alpha、Beta和Gamma。

这些数据库之间定义了一种复制关系，如下所示：

所有三个数据库都有一个名为“AnExample”的表，具有相同的模式。复制设置为Alpha是提供者，其他两个数据库是订阅者。

  1. 使用 MSDTC 事务（由 TransactionScope 处理）的 c#.Net 3.5 应用程序同时读取和写入数据库：Alpha 和 Beta。
  2. 此事务中的表“AnExample”仅在 Alpha 上更新。
  3. MSDTC 事务成功提交。
  4. “AnExample”表可能在Alpha中更新，更改立即复制到Gamma
  5. Beta上没有发生任何变化（分析器确认数据库上没有发生任何活动），SQL 日志或事件日志中也没有出现任何错误
  6. 使用相同的凭据重新运行在 Management Studio 中更新“AnExample”的相同查询成功（复制到Beta）
  7. 运行 MSDTC 事务 在Beta上写入另一个表，然后使用主应用程序 DAL、连接字符串和配置的测试应用程序对 Alpha 的“AnExample”表进行完全相同的写入（复制到Beta发生）

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

可能的线索/红鲱鱼

我们可以看到的成功测试与主应用程序使用的实际查询之间的唯一区别是隔离级别发生了某种变化。在成功的查询中，它被设置为仅读取已提交的事务隔离级别，而在失败的情况下它被设置为可序列化（尽管没有显式调用来更改代码库或存储过程中的隔离级别）。

我们确实觉得这在某种程度上是一个红鲱鱼，因为在 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*

这有点让人头疼。

4

2 回答 2

0

我假设这是事务复制？如果是这样，推送给订阅者的更改是由日志阅读器从事务日志中获取的，所以这个问题确实听起来很奇怪。

我会尝试在发布者数据库上运行跟踪，这样您就可以看到复制代理做了什么.. 不知道可能出了什么问题，但也许有些东西会跳出来。

于 2009-04-30T16:28:36.063 回答
0

所以我们发现了问题所在。如上所述; 我们有一个分布式事务写入Alpha然后Beta。然后，对Beta的写入成功地复制到Gamma它以静默方式失败到Alpha。然而，有一个遗漏是对Alpha的写入实际上正在复制到Beta（大型数据库模式的麻烦）。将此写入移至Beta意味着复制突然成功。

我还没有看到它记录了通过分布式事务进行的更新不能以一种方式进行复制，但公平地说，这是一个有点模糊的问题，只需确保对复制表的所有写入都发生在同一个数据库上即可解决。

希望这对其他人有帮助。

于 2009-05-07T09:33:48.827 回答