一个事务复制的bug--更新丢失 续

阅读本文之前请参考 最近又做了一个case，环境是sql server 2008 R2. 客户添加了一个'replication support only'的订阅，之后发现现存订阅出现了更新丢失。 丢失的数据恰巧是添加订阅前的几秒钟内生成的。 我开始以为是log reader没有开启造成的，检查了dist

阅读本文之前请参考

最近又做了一个case，环境是sql server 2008 R2. 客户添加了一个'replication support only'的订阅，之后发现现存订阅出现了更新丢失。 丢失的数据恰巧是添加订阅前的几秒钟内生成的。

我开始以为是log reader没有开启造成的，检查了distribution database的MSlogreader_history

,发现期间log reader并没有停止过。

如果Log reader停止，那么添加订阅前的更新肯定是丢失了。因为产生的数据的LSN小于"添加订阅"的LSN， 并且distribution agent把"添加订阅"的LSN先传递到了订阅。可是log reader一直处于运行状态，那么还有什么可能呢？ 如果log reader的效率很低，，没有即时地将数据更新传递到distribution agent，那么也会产生这个问题吧？我想理论上是这样的,如果效率非常低，可以等同于log reader没有运行! 那么如何证明这一点呢？reproduce的过程可能会很复杂，而且客户的磁盘性能也很好…

我想到了另外一种可能，这个问题实际上和log reader的工作方式有关系：

当log reader启动后，会去读取publication database的日志，如果一次读取完后，如果publication database的日志中仍然有需要处理的数据，log reader会继续读；如果读取后没有数据需要处理，log reader会休息一段时间， 时间长度为PollingInterval的值（默认为5秒中）。 那么我们假设这样的情景。

PollingInterval为五秒。Log reader启动后发现没有数据需要读取，开始休息。

在第1秒的时候，其中的article a产生了数据更新

在第2秒的时候，其中的article b产生了数据更新

在第3秒的时候，添加了一个非snapshot方式初始化的订阅。

在第4秒的时候，其中的article c产生了数据更新

在第5秒的时候，其中的article d产生了数据更新

同时log reader开始继续扫描日志， 我们就会发现第一秒和第二秒的数据更新丢失了。

更多信息

1 向任意一个包含'replication support only' 订阅的发布添加article时都可能会导致这个发布库的所有发布的所有现存订阅出现更新丢失的问题。

向不包含'replication support only'订阅的发布添加不会有这个问题。

2 如果在添加一个'replication support only'的订阅时 ，该发布对应的发布数据库的所有已存在订阅也会出现更新丢失的情况，无论这些都订阅通过何种方式初始化，或属于那个发布。

解决方法之前文章介绍的相同

解决办法

===

升级至sql servr 2012

如果您暂时没有办法升级，可以采用以下两种方法：

添加一个新的发布，将新的article或订阅添加到发布中。