SQL Server 合并复制问题答案

【问题标题】：SQL Server Merge Replication ProblemsSQL Server 合并复制问题
【发布时间】：2009-12-09 13:36:23
【问题描述】：

我在 CRM 系统上设置了合并复制。销售代表在连接到网络时会合并数据（我认为当 SQL 检测到笔记本电脑已连接时），然后他们将笔记本电脑拿走并在他们回来时再次合并（总共大约 6 台笔记本电脑通过 1 个服务器合并）。

这个系统在最初设置时似乎很好，但在大约一个月过去后它几乎停止了，合并作业需要将近 2 个小时才能运行，每个用户，服务器没有任何挣扎。

如果我删除整个出版物并重新创建所有订阅，它似乎可以正常工作，直到大约再过一个月，然后我又回到了同样的问题。

数据库设计不佳，缺少主键/索引等，但最大的表只有大约 3000 行。

有谁知道为什么会发生这种情况，以及在删除和重新创建出版物时是否存在丢失数据的风险？

【问题讨论】：

用户多久同步一次？是否有报告或管理员编写他们每月运行的数据？
一些用户每天同步，因为大约 70% 的时间都有电脑在网络上，而一对夫妇只有几次网络上的笔记本电脑，或者每周一次，时间很短时间，大约一两个小时。如果有任何人需要或更多信息，请发表评论。
没有什么是按月运行的，刚刚检查了昨晚的最后一次同步花了 5.5 小时完成
我注意到复制监视器中经常出现一条消息：在轮询进一步更改之前等待 60 秒知道为什么要等待这么长时间吗？或者我是否可以更改设置？
这里的问题似乎是元数据的积累。如果我将保留期设置为 14 天（目前永不过期），有谁知道，如果其中一位销售代表在该期限后返回，他们所做的更改会丢失吗？或者当订阅重新初始化时他们会被接走

【解决方案1】：

问题是由 sql server 复制创建的元数据，有一个通宵作业清空并重新填充 3000 行表。这会导致复制每天复制所有这些行。

订阅设置为永不过期，这意味着旧的元数据永远不会被 sql server 删除。

我现在将订阅期设置为 7 天，希望在此期间之后它会清理元数据。我做了一些测试，证明如果订阅过期，更改不会丢失。但是服务器上的任何更新都优先于客户端。

【讨论】：

【解决方案2】：

我最近在 2008 R2 中遇到了“在轮询进一步更改之前等待 60 秒”。

复制监视器显示复制的“进行中状态”，但只执行了第 1 步（初始化）和第 2 步（架构更改和批量插入）。我很疑惑为什么其他步骤没有执行？

原因很简单——似乎合并复制需要 tcp/ip（或不确定）命名管道协议激活。

没有报告错误。

可能类似的问题（某种连接问题）在 Ryan Stephens 案例中变得很明显。

【讨论】：