﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / SQL Server 2005 / SS2K5 Replication  / Replication - Performance Problem / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Thu, 23 May 2013 09:17:39 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: Replication - Performance Problem</title><link>http://www.sqlservercentral.com/Forums/Topic974706-291-1.aspx</link><description>Not sure if merge allows it, but in transactional replication you can test the latency of replication with a "trace toker". Just google'd and it isnt. DohWith a varying number of connection speeds I would personally add from warning within the replication publication. MSDN has some info within the link below[url]http://msdn.microsoft.com/en-us/library/ms152768%28v=SQL.90%29.aspx[/url]</description><pubDate>Thu, 26 Aug 2010 04:11:20 GMT</pubDate><dc:creator>sql_lock</dc:creator></item><item><title>RE: Replication - Performance Problem</title><link>http://www.sqlservercentral.com/Forums/Topic974706-291-1.aspx</link><description>They connect over the internet, using a VPN and the quality of connection varies, some have cable, some use 3G.One of the tables has about 17M records, but the filtering reduces it to a max of 5000The other tables have only about 50m records maximum.Some data is shared, but only about 10%Thank you</description><pubDate>Thu, 26 Aug 2010 04:04:53 GMT</pubDate><dc:creator>jose.g.korndorffer</dc:creator></item><item><title>RE: Replication - Performance Problem</title><link>http://www.sqlservercentral.com/Forums/Topic974706-291-1.aspx</link><description>How are your subscribers connected - over the internet?How big is your filtered database?</description><pubDate>Thu, 26 Aug 2010 03:45:25 GMT</pubDate><dc:creator>Stupeo</dc:creator></item><item><title>RE: Replication - Performance Problem</title><link>http://www.sqlservercentral.com/Forums/Topic974706-291-1.aspx</link><description>Hiwe have the distribution database on the same server, and we have performance problems when the merge is done, even when there are no changes, more especifically when having more than 20 concurrent replicating subscribers and whenever we do an initial replica.   In fact our main concern now is how to change anything as doing changes to the tables, (published articles), has become impossible as it would require to much time.(BTW Subscribers are using pull subscriptions and we are using filters).Thank you</description><pubDate>Thu, 26 Aug 2010 02:57:45 GMT</pubDate><dc:creator>jose.g.korndorffer</dc:creator></item><item><title>RE: Replication - Performance Problem</title><link>http://www.sqlservercentral.com/Forums/Topic974706-291-1.aspx</link><description>What sort of performance issues are you having exactly? Is it the actual process of the merging that's running slowly? Are you using push or pull subscribers? Is the Distribution db on the publisher server or seperate?</description><pubDate>Wed, 25 Aug 2010 13:11:10 GMT</pubDate><dc:creator>Stupeo</dc:creator></item><item><title>Replication - Performance Problem</title><link>http://www.sqlservercentral.com/Forums/Topic974706-291-1.aspx</link><description>Hi,we are having a performance problem and we are trying to tune the database.Decisions were made long ago and here is what I found when I got here:Current system consists of a SQL Server 2005 Enterprise sp3 Cluster installation with logical disks residing in SANS and 1000 remote users with SQL Server 2005 Express.It has 4 merge publications and 1000 subscribers to each of them.  We usually have between 10 and 40 concurrent users, (the ones with the sql server express), replicating between 08:00 and 19:00 Monday to Friday, as they usually work remotely and may be replicating from 500 kms away or even more.Steps we have taken include:- Checking disks --&amp;gt; they seem to have problems coping with the workload but they perform quite well otherwise.- Checking indexes on server side--&amp;gt; they were causing problems but they are fixed now.- Improved performance of tempb by icreasing the number of files.- Reduced the time for the subscription to expire.- ...Any suggestion would be welcomeThanks,Gerardo</description><pubDate>Wed, 25 Aug 2010 03:32:00 GMT</pubDate><dc:creator>jose.g.korndorffer</dc:creator></item></channel></rss>