You might find this optimization article helpful:
http://www.microsoft.com/technet/pro.../sql/2000/main
tain/mergperf.mspx
As you are using continuous merge, are you using merge
because of its versatile conflict management? If you
don't have conflicts and have no need for autonomy, I'd
consider transactional with updating subscribers if speed
is an issue.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Thanks for link
Well I nead a conflict menager - clients can connect to any server as they
wish.
By the way some info:
to replicate 750 records 650 Bytes each to 6 SQL Server i nead (
approximately) :
- 23 seconds with 1024kbps,
- 143 seconds with 256kbps,
- 330 seconds with 128kbps
Best Regards
Wojciech Znaniecki
Uzytkownik "Paul Ibison" <Paul.Ibison@.Pygmalion.Com> napisal w wiadomosci
news:15c401c515df$a311f300$a401280a@.phx.gbl...
> You might find this optimization article helpful:
> http://www.microsoft.com/technet/pro.../sql/2000/main
> tain/mergperf.mspx
> As you are using continuous merge, are you using merge
> because of its versatile conflict management? If you
> don't have conflicts and have no need for autonomy, I'd
> consider transactional with updating subscribers if speed
> is an issue.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
Tuesday, March 20, 2012
Big replication
Labels:
article,
continuous,
database,
helpfulhttp,
maintain,
mergperf,
microsoft,
mspxas,
mysql,
optimization,
oracle,
pro,
replication,
server,
sql,
technet
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment