Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Merge replication limitations
- Thread starter Sabnac
- Start date
SemperFiDownUnda
Instructor
why are the managers picking the replication method?
If your database is designed for it and you have the network infrastructure to support it go for it.
Point out to them Replication isn't something you "Slap in" because it sounds neat. For it to perform well you have to design it into your enterprise application. The best systems partition data so that even with merge replication no sites will step on eachothers toes. The new data just folds into everyone elses. Often you employ multiple different replication methods for different parts of the database. Key tables can be snapshot replication and maintained (SQL Wise) Centrally and pushed out while other data can be set up for merge or even transactional replication.
Merge replication is not efficient if you have a bunch of sites, 80 qualifies for that easy in my book, and the application and database design hasn't been made to take in account all the other sites.
The last place I worked for they where only talking abouit 4 or 5 sites but I couldn't convince the programming team leader that it could be slapped in at the last minute but needed to be planned. But who am I, I'm just a MSDBA with almost 10 years of database design and administration under my belt. That white paper he glanced at over night made him the expert. Funny how his transactional replication over a 128 link was blocking people from viewing data 90% of the time.
There is the problem, managers getting a white paper or reading a trade mag and thinking they know all the ramifications then are up in arms when it isn't as easy as throwing a switch.
?¿?Do you think I have issues?¿?
If your database is designed for it and you have the network infrastructure to support it go for it.
Point out to them Replication isn't something you "Slap in" because it sounds neat. For it to perform well you have to design it into your enterprise application. The best systems partition data so that even with merge replication no sites will step on eachothers toes. The new data just folds into everyone elses. Often you employ multiple different replication methods for different parts of the database. Key tables can be snapshot replication and maintained (SQL Wise) Centrally and pushed out while other data can be set up for merge or even transactional replication.
Merge replication is not efficient if you have a bunch of sites, 80 qualifies for that easy in my book, and the application and database design hasn't been made to take in account all the other sites.
The last place I worked for they where only talking abouit 4 or 5 sites but I couldn't convince the programming team leader that it could be slapped in at the last minute but needed to be planned. But who am I, I'm just a MSDBA with almost 10 years of database design and administration under my belt. That white paper he glanced at over night made him the expert. Funny how his transactional replication over a 128 link was blocking people from viewing data 90% of the time.
There is the problem, managers getting a white paper or reading a trade mag and thinking they know all the ramifications then are up in arms when it isn't as easy as throwing a switch.
?¿?Do you think I have issues?¿?
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question