SQL Server Replication, Distributor -


I need to implement a SQL Server replication solution. I now have a very simple requirement for just 200 remote sites Either need to repeat a very simple table from a central server. Data is not really practical in nature. I need to reach the central server once in a day. I can not decide whether I should use a push or bridge, and I am not sure whether the distributor should be on the server side, or on all the clients.

Servers and all remote sites all live on a decent decent VPN. The server is 2005, and this time it is not being pushed very hard. There are only a few jobs here and there the data is collected (which I want to go away from) and forward the reports / exports to different vendors once in a day. Sites are a mixture of 2000/2005.

I recommend you first do some scalability testing. Replication agents are very important in terms of T-SQL connections to read and write jobs and data. 200 publications which you are talking about 200 publisher agents, 200 membership agents, as well as distributor maintenance. Most sites complain about the maintenance problems of having 1 publisher and 1 subscriber ... say that you manage to close it and successfully operate , what is the story of your upgrade Will be And how are you going to implement schema changes?

I've heard that the biggest replication deployment (some years ago) I believe in 450 publishers and was implemented by an army of Microsoft Field Advisers who was sweating for months. Your 200 replica sites project the way is more ambitious than you

I suggest that you also find some options. If you need periodic table snapshots, then SSIS can be a good match. If you need a continuous stream of changes, then the way it can be easier to replicate with


Comments

Popular posts from this blog

c# - How to capture HTTP packet with SharpPcap -

jquery - SimpleModal Confirm fails to submit form -

php - Multiple Select with Explode: only returns the word "Array" -