Hi all,
I am planning replication around a large SQL Database Server; 3 databases need to be replicated for reporting purposes.
My plan was to use Transaction Replication, as the Reporting database will be mostly read-only. However, we must add a whole bunch of additional, historical data to some of the tables of the reporting database that does not exist in the Publisher. I understand that changes can be made to subscriptions in Transaction Replication scenarios, ideally when the changes are few and far between. (Merge replication is excessive for our purposes.)
I don't want the additional historical data to be propagated back to the publisher. Is it possible that data is written to a subscriber in a Transactional Replication scenario without writing these updates to the Publisher? Given the nature of the data, there will not be conflicts between the historical data and the new changes applied from the publisher.
Any help would be much appreciated!
Thanks,
FarazWhile you are flirting at the edge of what works well, at least what you've described is possible. I'm pretty sure that Microsoft does not recommend it, I'm not sure if they support it, but I have done it under very limited circumstances for very specific purposes.
This is not for the faint of heart. You need to think things out carefully. It might pay you to find someone experienced in replication that you can contract to help set things up and shake out the problems.
-PatP|||Thanks for the reply. We won't be using transactional replication. In fact, from my understanding, one of the goals of replication is ensuring that data consistency is maintained between publishers and subscribers; in our case, we don't actually want the data to be consistent. Hence, we'll go forth with a less elegant, but far simpler solution.
Thanks again!
-Farazsql
Showing posts with label planning. Show all posts
Showing posts with label planning. Show all posts
Friday, March 23, 2012
Saturday, February 25, 2012
Replication issues with multiple databases
I am planning to use replication from 400 databases to the master database on
a periodic basis. Do you see any issues with that ?
All databases have the same structure
Alu,
this is a bit vague as it stands
but certainly this is 'possible'. In
this link they discuss scaling merge to 2000 subscribers:
http://www.microsoft.com/technet/pro...mergperf.mspx.
For your setup, the type of replication selected will have some
implications. There are also implications with the type of topology
selected, hardware available, bandwidth, data volume etc so really you just
have to implement it, monitor using Perfmon and then see how it goes. As an
aid to avoid contention (data and disk) you might need to consider
staggering synchronization.
Regards,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
a periodic basis. Do you see any issues with that ?
All databases have the same structure
Alu,
this is a bit vague as it stands
this link they discuss scaling merge to 2000 subscribers:
http://www.microsoft.com/technet/pro...mergperf.mspx.
For your setup, the type of replication selected will have some
implications. There are also implications with the type of topology
selected, hardware available, bandwidth, data volume etc so really you just
have to implement it, monitor using Perfmon and then see how it goes. As an
aid to avoid contention (data and disk) you might need to consider
staggering synchronization.
Regards,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Subscribe to:
Posts (Atom)