当我在不同系统中的数据库之间进行同步时,我在复制监视器中收到“长时间运行的合并”警告。由于我的数据库包含数十万条记录,因此执行需要一些时间,这会导致警告为“长时间运行的合并”。
它会影响记录转移还是我应该忽略警告?
需要采取什么步骤?
此警告的解决方案是什么?
当我在不同系统中的数据库之间进行同步时,我在复制监视器中收到“长时间运行的合并”警告。由于我的数据库包含数十万条记录,因此执行需要一些时间,这会导致警告为“长时间运行的合并”。
它会影响记录转移还是我应该忽略警告?
需要采取什么步骤?
此警告的解决方案是什么?
Long Running Merge 令人遗憾地回想起移动销售人员是合并复制的主要消费者的那一天。因此,在处理或多或少连续连接的服务器时,此警告/警报几乎是无用的。
换句话说,此警告是通过“警告”选项卡中的复制监视器配置的 - 您可以在其中指定以分钟为单位的时间阈值。
因此,假设我为 LAN 连接设置了 10 分钟的阈值。这意味着当合并复制代理的连接时间超过 10 分钟时,我希望收到警告。在笔记本电脑通过酒店的 VPN 连接的情况下,看到它们同步需要超过 10 分钟可能是有意义的。可悲的是,如果我们谈论的是一个已经运行了数小时或数天的专用合并代理,那么这将始终开启。
综上所述,我将上述陈述建立在两件事上:a)关于这些东西的确切含义的文档非常缺乏。我用谷歌搜索并查看了大量书籍,但只发现了这个: http ://www.kendalvandyke.com/2008/10/difference-between-long-merge-and-slow.html b)一组简单的测试我创建了一个新的/简单的出版物,然后一旦它启动并运行,我将阈值设置为 5 分钟。果然,发布成功同步5+分钟后,状态切换到'long running merge'
所以,虽然我不是 100% 肯定我的答案,但我相当有信心它是正确的。
同样,在处理合并/第二个阈值的行时,看起来那些也主要针对“旧”断开/重新连接的合并场景,而不是今天更常见的“始终连接”的情况(从而使它们相对无用作为监督机制)。