Long Running Merge

When I'm doing synchronization between database in different system, I'm getting the "long running merge" warning in the replication monitor. As my database consists of hundreds of thousands of records, so it is taking some time to execute which causes the warning as "long running merge".

Will it 开发者_运维知识库affect the records to transfer or should I just ignore the warning?

What are the step necessary to take?

What is the solution for this warning?

Long Running Merge sadly hearkens back to the day when mobile sales folks were the primary consumers of merge-replication. Consequently, this warning/alert is almost USELESS when dealing with more-or-less continually connected servers.

Stated differently, this warning is configured via Replication Monitor in the 'Warnings' tab - where you specify a time threshold in minutes.

So, say I set up a threshold of 10 minutes - for LAN connectivity. What that means is that I want to be WARNED when a Merge Replication agent has been connected for LONGER than 10 minutes. In the case of a laptop connected over a VPN from a hotel, it might make sense to see that they're taking > 10 minutes to synchronize. Sadly, if we're talking about a dedicated merge agent that's been running for hours or days, then this will ALWAYs be on.

All this said, I'm BASING the above statements on 2 things: a) an INSANE dearth of documentation on exactly what this stuff means. I've googled and looking in gobs of books and only ever found this: http://www.kendalvandyke.com/2008/10/difference-between-long-merge-and-slow.html b) a simple set of tests where I created a new/simple publication and then once it was up and running, I set the threshold to 5 minutes. Sure enough, after the publication had been successfully synchronizing for 5+ minutes, the status switch to 'long running merge'

So, while I'm not 100% positive of my answer, I'm fairly confident it's correct.

Likewise, in playing around with the rows merged/second threshold it looks like those too are geared primarily at 'older' disconnected/reconnected merge scenarios rather than 'always connected' situations that are much more common today (thereby making them relatively useless as a monitoring mechanism as well).