#merge replication

[varindersandhu-blog]

Post has been published on Varinder Sandhu 's Blog

Post has been published on http://www.varindersandhu.in/2011/05/14/understanding-of-replication/

SQL Server – Understanding of Replication

The primary purpose of replication is to distribute data from a master database to one or more secondary databases. Because Replication maintains a duplicate copy of data in synchronization with the master copy, the technology can be used to provide availability for application.

Type of Replication

Snapshot

Transactional

Merge

Snapshot Replication

Snapshot Replication takes the entire set of data and sends it during the each cycle of replication. This is full copy of data that is sent by Publisher to subscriber.

Transactional Replication

Users obtain complete initial copies of the database and then obtain periodic updates as data changes.

We can configure transactional replication with two optional modes:

Immediate updating subscriber

Queued updating subscriber

Transactional Replication can be deployed in two alterative architectures:

Bidirectional transactional replication

Peer-to-peer transactional replication

<!-- google_ad_client = "pub-2404605494811633"; google_alternate_color = "FFFFFF"; google_ad_width = 468; google_ad_height = 60; google_ad_format = "468x60_as"; google_ad_type = "text_image"; google_ad_channel =""; google_color_border = "FFFFFF"; google_color_link = "0000FF"; google_color_bg = "FFFFFF"; google_color_text = "000000"; google_color_url = "008000"; google_ui_features = "rc:6"; //-->

Merge Replication

In merge replication received the data from two or more publishers is combined into a one subscriber.

Data Conflicts

Data conflicts can occurs within any environment that enable distributed processing of transaction.

Type of Conflicts

Three type of conflicts can occurs

The insertion of a duplicate prinmary key on both publisher and subscriber

A conflicting update same row at both publisher and subscriber

An update of a nonexistent row

For more detail go to

http://msdn.microsoft.com/en-us/library/ms151198.aspx

http://msdn.microsoft.com/en-us/library/ms151215.aspx

[lewisjpaul]

Databases never seemed to be static things….

SQL is the queen of Relational Database Management Systems (RDBMS). RDBMS are enhanced when taking advantage of XML. XML provides tags that can be included in a text document in order to define it’s structure, allowing for greater management and manipulation of your data. If you want to be anti-fragile, then its time to build a Data Warehouse. Your going to need your Data Warehouse to be malleable, but also representing your organization’s history. If you find yourself growing beyond a one stop shop, then you may need to plan building data marts, subsets for your Data Warehouse that have a particular data focus. Replication is a beautiful thing Consider the Publisher, owner of data, defines the data given to subscribers, at different locations. Sometimes subscribers need to write back to the publisher to enhance the story. That’s when we’ll call on a merge replication, so the subscriber’s contribution can synchronize with the publisher’s. Merge Replication is great when you need to allow multiple users to develop data independently and later unit their information. Data Warehouse parties can be exclusive Context matters. Constraints on your data are vital, if none of the data is unique then its hard to make it work anything. Its up to you to set the Rules on what data types are acceptable in a column. Its hard to find the answer for ‘2 + apple.’ Not every table is an island You’re going to need ways of confidently importing and moving data from multiple sources regularly. Depending on the services you provide you may need to conduct Online Transaction Processing (OLTP) to keep tabs on your users’ exchanges of data. Storing this information will allow you to figure out trends in your data warehouse later.