June 18, 2007 at 3:19 am
Hello,
I'm hoping one of you good people could help me out with a baffling problem I've been experiencing...
Here's the setup:
SQL Server 2000. One Publisher, three subscribers. Merge replication with continuous updates.
When I first set it up, I was having problems with the replication agents stopping for various minor reasons (eg "the process could not enumerate changes at the 'Publisher'") , but it always restarted when requested. This became a bit of a nuisance, so I did some research and someone suggested setting step 3 of the replication properties ("Detect nonlogged agent shutdown") to "Goto step 1 (merge agent startup) on success". This worked well and meant that I didn't have to keep checking the status of the agents, because eventually they always restarted.
The above may or may not be relevant to my current problem, which is:
When a merge agent fails, the time difference between "last action" of one session and the start of the next session is usually a few seconds.
However, over the weekend each of the three subscribers had a session log which terminated with "Could not connect to subscriber xxx", with a last action time of 14:49. In each case the next session started at 21:32.
My question isn't why it failed, I know there was a connectivity issue yesterday, but why it didn't try again until 21:32.
This has happened several times, sometimes when there wasn't a connection problem.
Any ideas would be gratefully received
Thanks
Ken
June 19, 2007 at 11:22 pm
You can increase the # of attempts it can try to reconnect when it fails to connect. Agent will keep on retrying till it reached the # of attempts.
This can be done by modifying the system job (merge) created for replication purpose
HTH
rangark
June 20, 2007 at 2:37 am
Thanks for the input Rangark.
However, I'm afraid I've misled you all, but there is still something curious.
It turns out that somebody has scheduled a daily reboot of the server at about 21:15. It appears that the reboot causes the history of the current merge session to be lost (I've searched MSMerge_History and there's nothing there!), thus making it look like nothing has been attempted for a time. Can anybody shed any light on whether this is the case and, if so, what the reason could be and how I can prevent it
Thanks as always
Ken
June 21, 2007 at 12:00 am
Do not worry about Msmerge_history being cleanup, since this table is bound to be cleanup anyway, automatically by way of system clean up scheduled task,which is autocreated during replication setup.
Just check whether the sql agent is also scheduled to restart when the reboot happens...
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply