August 6, 2013 at 11:39 pm
Hi
here i want some clarification on replication.
1) i want to know what is the difference between snapshot,transactional,merge,transaction with updatable sub replication
2) how each replication method will work.
here in my environment we have a large table in production database which has 4lacs records.
in that they have the access to users for reporting purpose due to that load is increasing on server so we want to configure the merge replication to ship the data in to another server.
here in merge replication if we did any changes in subscriber end those changes will reflect in publisher as well or not ?
please help me regarding usage and funcationality of replication.
August 9, 2013 at 1:55 am
please help me on above questions
August 19, 2013 at 9:57 am
You would probably be best doing a google search for the information about different types of replication. To explain everything in detail would take somebody a long time to type.
August 20, 2013 at 8:30 am
[font="Comic Sans MS"]Hi,
I'll be brief in my explanation.
Snapshot replication distributes data exactly as it appears at a specific moment in time and does not monitor for updates to the data. When synchronization occurs, the entire snapshot is generated and sent to Subscribers.
Transactional replication typically starts with a snapshot of the publication database objects and data. As soon as the initial snapshot is taken, subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur (in near real time). The data changes are applied to the Subscriber in the same order and within the same transaction boundaries as they occurred at the Publisher; therefore, within a publication, transactional consistency is guaranteed.
Merge replication, like transactional replication, typically starts with a snapshot of the publication database objects and data. Subsequent data changes and schema modifications made at the Publisher and Subscribers are tracked with triggers. The Subscriber synchronizes with the Publisher when connected to the network and exchanges all rows that have changed between the Publisher and Subscriber since the last time synchronization occurred.
Why do you want to implement Merge Replication when the same can be done through snapshot/transactional replication if it's only for transferring data for reporting purposes.
[/font]
August 20, 2013 at 10:01 am
Thanks for your response
as per my client requirement we have one table which is having 5cr records presently we are given the access to users on production.
they want to reduce the load on prod so we want to configure the merge replication. here in the article properties synchronization mode is showing as bidirectional due to that performance is decreased.
so here which mode we have to choose. here user can change the data in subscriber as well.
August 20, 2013 at 11:07 pm
[font="Comic Sans MS"]I believe 5 cr request is not that huge. We have a setup with transactional replication that transfers millions of records for reporting purposes each day. As per your client requirement you need bidirectional flow of data so I would suggest to go with "Transactional Replication with Updates". I still don't understand the need to go for Merge Replication, you only would complicate things as it's kinda difficult to manage, and the requirement which you've provided doesn't support that either.
Check on BOL for more info.[/font]
August 21, 2013 at 2:48 am
thanks for your valuable information
in transactional replication with updates can we change any modifications on subscriber and those will reflect in publisher as well
August 21, 2013 at 2:55 am
[font="Comic Sans MS"]You're welcome.
Yes it does push the changes made at the subscriber back on to the Publisher.[/font]
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply