Adjust SQL Server for Long TCP Latencies

  • Hi There,

    I am having a serious problem with what was a successful merge replication deployment to two SQL2000 (on win2k) servers on the end of VSAT connections.

    Unfortunately, my ISP has been struggling to maintain the network quality and now I am getting TCP latencies of +4s and the merge replication is failing to work. This has now created a logjam of data waiting to be sent

    Is there any setting I can change that will make the system more tolerant?

    I am relatively new to this, and would appreciate any help whatsoever.

    Sincerely

    Martin Rowe

  • By design, merge replication is very resilient.

    When you say it fails to work, are you getting any replication errors or is it just the case that the network/connection that you are currently using is just not stable enough.

    Are you seeing any packet drops across the network connection ?

    Graeme

  • Hi Graeme,

    Thanks a million for the reply.

    I get pretty poor daytime bandwidth with +20% and high latencies of +4s. It rarely manages to contact the subscriber during this time.

    At night the bandwidth hovers between 0.9s and 4s.

    At this time the system seems to send a couple of hundred records before it has an issue and gives a "could not deliver insert to subscriber" error. It will then start replication again, it will briefly show No Data Needed to be Merged before sending data, but it never seems to be able to complete the inserts.

    Cheers

    Martin

  • Can you try 'pinging' or using Tracert to see what sort of times (in ms) you are getting?

  • You can adjust the merge agent profile for slow connections. For example selecting a smaller batch size or higher timeout values. If I remember right there's also a build in profile for slow connections.

    See here for more info http://msdn.microsoft.com/en-us/library/aa237187(SQL.80).aspx

    [font="Verdana"]Markus Bohse[/font]

  • Hi There,

    When I ping the subscriber during the day I get 25% + packet loss with average times of +/- 4000ms

    Night time bandwidth is much better with 1% packet loss and times of 900ms to 4000ms. It seems to vary between the two every 30 seconds, which I think might be the heart of the problem

    Cheers

    Martin

  • Hi Marcus,

    I did change the system to the slow link profile, but I was still struggling.

    I then resorted to making my own custom one, but it did not work at all, most likely due to an "acute talent shortfall" on my part.

    I will read the link you sent with great interest.

    Thanks very much

    Martin

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply