MS-SQL Server 2005:复制后的非聚合数据 [英] MS-SQL Server 2005: non convergent data after replication

问题描述

我们有一个合并复制拓扑，包括一个发布者、多个发布者和多个订阅者.它已经运行了至少 8 个月没有问题.

We have a merge replication topology including one publisher, multiple publications and multiple subscriptions. It has been running for at least 8 months without problems.

几天前我被告知我的采购订单代码被无故更改"，从标准的ZWWTP/PO-0092"样式到新的ZWWT"样式:采购订单代码中的字符 5 到 8被更改为另一个字符串 chr(0) &chr(1) &chr(0) &某些服务器上的 chr(1)

A few days ago I was informed that my PO codes were being "changed" without any reasons, from a standard "ZWWTP/PO-0092" style to a new "ZWWT" style: characters 5 to 8 in the PO code were changed to another string being chr(0) & chr(1) & chr(0) & chr(1) on some servers

我发现似乎只有我的一个复制/订阅过程生成了这样的虚拟数据:发布者和这个特定订阅者上的 PO 代码与最近更新或添加的记录不再匹配.在订阅者端创建的 PO 的代码在上传到发布者时将被更改(在订阅者端保持干净).从发布者下载的 PO 将在订阅者上传播，并带有更改的 PO 代码.

I reached the point where it appeared that one only of my replication/suscription processes was generating such dummy data: PO codes on the publisher and this specific subscriber did not match anymore for recently updated or added records. Codes for POs created on subscriber's side will be altered when uploaded to the publisher (staying clean on the suscriber's). POs downloaded from the publisher will be propagated with an altered PO code on the subscriber.

然后我能够使用一些表比较实用程序 + 一些 UPDATE 语句清理/调整两台服务器上的数据，但是现在每次在两台服务器之间运行复制时都会出现非常相同的差异:我在两台服务器上的清理/相同数据运行成功复制后，服务器将被设置回其非收敛状态:相同的记录，相同的值！

I was then able to clean/adjust the data on both servers with some table compare utilities + some UPDATE statements, but the very same discrepancies now appear each time a replication runs between the two servers: my clean/identical data on both servers will be set back to its non convergent state after a succesfull replication is run: same records, same values!

我认为我在网络上没有留下太多关于数据融合和复制的可用资源.我没有找到任何东西.我计划在 3 小时内抛出/重建现有的发布/订阅，但我仍在寻找合理的答案，以免我的问题变成精神分析问题:

I don't think I left much of available ressources on the net concerning data convergence and replication. I did not find anything. I am planning to throw/rebuild the existing pubication/subscription in 3 hours, but I am still looking for a rationnal answer to my problem before it turns into a psychoanalytic issue:

有人知道发生了什么吗?

PS:顺便说一下，由于 PO 代码不用作自然键，因此此复制问题对数据库完整性没有影响.另一个支持代理键总是有效的论据与大部分时间都有效的自然键相反，但是这已经在别处讨论过 ...

PS: by the way, as the PO code is not used as natural key, this replication issue has no impact on database integrity. One more argument in favor of surrogated keys that allways work in opposition to natural keys that work most of the time, but this has been discussed somewhere else ...

嗯，我做到了，但没有奏效！我同时抛出订阅和发布，重新创建发布，但我无法生成快照.服务器无法管理它所谓的发布者的身份范围分配条目"，无法在系统表 MSmerge_identity_range 中找到.

well, I did it, and it DID NOT WORK! I threw both the subscription and the publication, recreated the publication, but I was then unable to generate a snapshot. The server was not able to manage what it calls "The identity range allocation entry for the Publisher", which "could not be found in the system table MSmerge_identity_range.

浏览后，我发现这篇文章说当你掉线在发布数据库中创建的第一个发布"

After browsing, I found this article saying such a problem can occur when "You dropped the first publication that was created in the publication database"

多有趣啊！这正是我刚刚做的！

How funny it is! This is exactly what I just did!

幸运的是，这个问题应该可以通过 SQLServer 2005 累积包 5 解决，我仍然需要下载和安装.但现在的问题是:在这个 CP5 发布之前，SQLServer 2005 用户是如何工作的?

Fortunately, this problem is supposed to be solved with SQLServer 2005 cumulative pack 5, which I still have to download and install. But the question is now: how did the SQLServer 2005 users could work before the release of this CP5?

累积包 5 不起作用，我仍然无法为我的新复制创建快照！

the cumulative pack 5 did not work and I am still not able to create a snapshot for my new replication!

推荐答案

我认为你的计划是正确的 ;)

I think you have the right plan ;)

这篇关于MS-SQL Server 2005:复制后的非聚合数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！