Replication means making exact copy or synchronize from source database to target with interval of time. So if source data get inserted then for short time target data will get inserted with same data from source.
Same as delete operation, if some records in source data deleted then same data in target table will deleted.
From technical point of view, Replication and Mirroring are different. Replication is synchronization process between databases and intended to be used by day to day application. Whereas mirroring is intended for high availability and data protection of database. So if live database corrupted then mirror database will be used automatically.
However from non technical point of view, they as if similar. Both source & target (secondary) server has same data but replication can have sql query in order to replicate for just specific data and/or combined data.
For some reasons, we want to have a replica for our database. In example, you have two servers with almost or same specification, one server is serving OLTP and other intended to reporting server.
The OLTP server will supply or export its data to Reporting Server, so that overall application load will be devided.
This export data from OLTP to Reporting can be done automatically using SQL Server 2008 R2 Replication. Users do transactional data from their application, data saved to OLTP database.
After that replication do insert or update or delete according source data in short time interval to target which is Reporting database. This makes exact state of data between source & target.
Another example is distribute central data to branches or vice versa. Let’s say you have central data that inputted by head office staffs.
You want some of the data to be distribute to branch servers so that branch users can view central data from their own server.
This also can be done using replication.
SQL Server Replication explanation
Copying some definitions from MS technet site => http://technet.microsoft.com/en-us/library/ms152567.aspx
Replication uses a publishing industry i.e magazine and/or newspaper metaphor to represent the components in a replication topology, which include Publisher, Distributor, Subscribers, publications, articles, and subscriptions.
The Publisher is a database instance that makes data available to other locations through replication. The Publisher can have one or more publications, each defining a logically related set of objects and data to replicate.
The Distributor is a database instance that acts as a store for replication specific data associated with one or more Publishers. Each Publisher is associated with a single database (known as a distribution database) at the Distributor. The distribution database stores replication status data, metadata about the publication, and, in some cases, acts as a queue for data moving from the Publisher to the Subscribers. In many cases, a single database server instance acts as both the Publisher and the Distributor. This is known as a local Distributor. When the Publisher and the Distributor are configured on separate database server instances, the Distributor is known as a remote Distributor.
A Subscriber is a database instance that receives replicated data. A Subscriber can receive data from multiple Publishers and publications. Depending on the type of replication chosen, the Subscriber can also pass data changes back to the Publisher or republish the data to other Subscribers.
An article identifies a database object that is included in a publication. A publication can contain different types of articles, including tables, views, stored procedures, and other objects. When tables are published as articles, filters can be used to restrict the columns and rows of the data sent to Subscribers.
A publication is a collection of one or more articles from one database. The grouping of multiple articles into a publication makes it easier to specify a logically related set of database objects and data that are replicated as a unit.
A subscription is a request for a copy of a publication to be delivered to a Subscriber. The subscription defines what publication will be received, where, and when. There are two types of subscriptions: push and pull.
How To Do
This blog post will show you step by step to do replication using SQL Server 2008 R2 in easy way.
Also I only use 1 computer only for demonstration although replication is usually meant for syncing to another computers.
- Set up your source database and table. This source database acts as Publisher.
I called source database
TestDBand its table
Below is create script for tb_person:
CREATE TABLE [dbo].[tb_person]( [Name] [nvarchar](50) NULL, [City] [nvarchar](50) NULL, [Province] [nvarchar](50) NULL, [ID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL, CONSTRAINT [PK_tb_person] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]
- Set up your target database and table. This target database acts as Subcriber
I created the target database
TestRepland its table name is same as Publisher which is
Create the Publication
This is one way synchronization. You can choose others choice if you want to.
Right click on publication and choose Properties. Go to snapshot and specify its folder.
The snapshot folder is used to share replication data. So Make sure this folder can be full accessed by Agent Security account.
If your subscriber is database of other PC/server then this snapshot folder must be accessed from network user.
- Expand Replication folder, Local Subscriptions, right click, New Subsriptions
- Click Next on Welcome screen and then choose your publication that you created earlier
- Choose where to run the Distribution Agent(s). I use pull subcription to reduce processing overhead at Distributor and/or Publisher.
Other choice is push subscription which is publisher pushing snapshot to subscribers when changes are made. However you must be careful especially with heavy daily transaction. It could slowdown publisher performance.
- Choose subscriber database. In this demo, I use my own ‘TestRepl’
- Specify Subscriber process account and connection to Distributor account. I use Windows user id & password.
- Specify the synchronization schedule. This decide when or how copying/syncing data has to occur. I
You can schedule it with a time interval or daily, weekly.
- Specify whether to initialize this subscription. Subsription must be initialize to start replication process.
In large table with a lot of transaction in minutes should better initialize in off peak hours.
- Create the subscription and click next
- Complete the subsription’s wizard by clicking finish
Test The Replication
You might want to test it. Just try to insert/update/delete data in source / publisher database table which in this demo is ‘tb_person’ in TestDB database.
After that please look or use select query on target / subscriber database table, ‘tb_person’ in TestRepl database. They should be synced automatically.