Introduction to Replication
Replication is the process of sharing data between databases in different locations.
Using replication, we can create copies of the database and share the copy with
different users so that they can make changes to their local copy of database and
later synchronize the changes to the source database.
Microsoft SQL Server replication uses publisher, distributor and subscriber
entities.
Publisher is a server that makes the data available for subscription to other servers.
In addition to that, publisher also identifies what data has changed at the subscriber
during the synchronizing process. Publisher contains publication(s). Publication is
a collection of one or more articles that is sent to a subscriber server or database.
Subscriber is a server that receives and maintains the published data. Modifications
to the data at subscriber can be propagated back to the publisher.
Distributor is the server that manages the flow of data through the replication
system. Two types of distributors are present, one is remote distributor and the
other one local distributor. Remote distributor is separate from publisher and is
configured as distributor for replication. Local distributor is a server that is
configured as publisher and distributor.
Agents are the processes that are responsible for copying and distributing data
between publisher and subscriber. There are different types of agents supporting
different types of replication.
An article can be any database object, like Tables (Column filtered or Row filtered),
Views, Indexed views, Stored Procedures, and User defined functions.
Publication is a collection of articles.
Subscription is a request for copy of data or database objects to be replicated.
Type of Subscriptions
Changes to the subscriptions at the publisher can be replicated to subscribers via
PUSH subscription or PULL subscription.
Push subscription is subscription when the publishing server will periodically push
transactions out to the subscribing server or database. With Push subscription, the
publisher is responsible for synchronizing all the changes to the subscriber without
subscriber asking for those changes.
Pull subscription is subscription when the subscribing server will periodically
connect to the distribution database and pull information. With Pull subscription,
the subscriber initiates the replication instead of the publisher.
The Distribution database is a system database, which is stored on the Distributor
and does not contain any user tables. This database is used to store snapshot jobs
and all transactions waiting to be distributed to Subscribers.
Replication topologies
Microsoft SQL Server supports the following replication topologies:





Central publisher
Central subscriber
Central publisher with remote distributor
Central distributor
Publishing subscriber
Central Publisher
This is one of the most used replication topologies. In this scenario, one server is
configured as Publisher and Distributor and another server/servers is/are configured
as Subscriber/Subscribers.
Central Subscriber
This is a common topology in data warehousing. Many servers or databases replicate
their data to a single central server in one or more databases.
Central Publisher with Remote Distributor
In this topology, the distribution database resides on another server than publisher.
This topology is used for performance reasons when the level of replication activity
increases or the server or network resources become constrained. It reduces
Publisher loading, but it increases overall network traffic.
This topology requires separate Microsoft SQL Server installations, one for the
Publisher and one for the Distributor.
Central Distributor
In this topology, several publishers use only one distributor, which resides on
another server than publishers. This is one of the most rarely used replication
topologies because it has only single point of failure (on the single server with central
distributor), and if distributor's server will fail, the entire replication scenario will be
destroyed.
Publishing Subscriber
This is a dual role topology. In this topology, two servers publish the same data. One
publishing server sends data to the subscriber, and then this subscriber publishes
data to any number of other subscribers. This is useful when a Publisher must send
data to Subscribers over a slow or expensive communications link.
Replication Types
Microsoft SQL Server 7.0/2000 supports the following types of replication:



Snapshot Replication
Transactional Replication
Merge Replication
Snapshot Replication
Snapshot Replication is the simplest type of replication. With this kind of
replication, all replicated data (replica) will be copied from the Publisher database to
the Subscriber's/Subscribers' database(s) on a periodic basis. Snapshot replication is
best used as a method for replicating data that change infrequently and when the
size of replicated data is not very large.



Snapshot replication is also known as static replication. Snapshot replication
copies and distributes data and database objects exactly as they appear at
the current moment in time.
Subscribers are updated with complete modified data and not by individual
transactions, and are not continuous in nature.
This type is mostly used when the amount of data to be replicated is small
and data/DB objects are static or does not change frequently.
Transactional Replication
With Transactional Replication, SQL Server captures all changes that were made
in an article and stores INSERT, UPDATE, and DELETE statements in the distribution
database. These changes are then sent to subscribers from the distribution database
and applied in the same order. Transactional replication is best used when the
replicated data changes frequently or when the size of replicated data is not small
and is not necessary to support autonomous changes of the replicated data on the
Publisher and on the Subscriber.



Transactional replication is also known as dynamic replication. In
transactional replication, modifications to the publication at the publisher are
propagated to the subscriber incrementally.
Publisher and the subscriber are always in synchronization and should always
be connected.
This type is mostly used when subscribers always need the latest data for
processing.
Merge replication
With Merge Replication, SQL Server captures all incremental data changes in the
source and in the target databases, and reconciles conflicts according to rules you
configure or using a custom resolver you create. Merge replication is best used when
you want to support autonomous changes on the replicated data on the Publisher
and on the Subscriber.
Replication agents involved in merge replication are Snapshot Agent and Merge
Agent.
Implement merge replication if, changes are made constantly at the publisher and
subscribing servers, and must be merged in the end.
By default, the publisher wins all conflicts that it has with subscribers because it has
the highest priority. Conflict resolver can be customized.
Replication agents
Microsoft SQL Server 7.0/2000 supports the following replication agents:




Snapshot Agent
Log Reader Agent
Distribution Agent
Merge Agent
The Snapshot Agent is a replication agent that make snapshot files, stores the
snapshot on the Distributor, and records information about the synchronization
status in the distribution database. The Snapshot Agent is used in all replication
types (Snapshot, Transactional, and Merge replications) and can be administered by
using SQL Server Enterprise Manager.
The Log Reader Agent is a replication agent that moves transactions marked for
replication from the transaction log on the Publisher to the distribution database.
This replication agent is not used in Snapshot replication.
The Distribution Agent is a replication agent that moves the snapshot jobs from
the distribution database to Subscribers, and moves all transactions waiting to be
distributed to Subscribers. The Distribution Agent is used in Snapshot and
Transactional replications and can be administered by using SQL Server Enterprise
Manager.
The Merge Agent is a replication agent that applies initial snapshot jobs from the
publication database tables to Subscribers, and merges incremental data changes
that have occurred since the initial snapshot was created. The Merge Agent is used
only in Merge replication.
How to Implement a Merge Replication
Necessary steps to be taken before doing replication process:
Check the following before setting up Merge replication:
1. The Localsystem account has no access to shares on the network as it isn't an
authenticated network account.
That is if you want to set up replication you must change the account the
MSSQLServer and SQLServerAgent services runs under to an account with the
Windows NT/Windows 2000 administrator's rights. If your Microsoft SQL Server runs
on Windows NT or Windows 2000, you can create a Windows NT/Windows 2000
account and include it into local Administrators group, into Domain Users group, and
set Log in as a service permission for this account.
So, Before starting the replication process, change the log on account for the
MSSQLSERVER service as “This account”. Use any SQL login account which is a
member of sysadmin server role. Please see the screenshot for more information.
Windows 9x does not support Windows NT services, so if your Microsoft SQL Server
runs on Windows 9x, you do not need to create SQL account.
2. Only members of the sysadmin server role can set up and configure replication, so
if you have not this rights, you can not set up replication.
3. Don't forget to start SQLServerAgent service and MSSQLServer service.
4. You should allocate adequate disk space for the distribution database.
5. You should allocate adequate disk space for the publisher's and subscribers'
databases.
SQL Server 7.0/2000 uses the uniqueidentifier column to identify each row during
the merge replication, so if your table does not have a uniqueidentifier column with
the ROWGUIDCOL property, Microsoft SQL Server 7.0/2000 will add this column to
the table. So, you need to allocate additional disk space to store your data.
6. You cannot replicate only one table with foreign key constraints; you should
include all referenced tables in the publication.
7. You should ensure the server that is being replicated to is defined as a remote
server.
Step by Step Procedure for Merge Replication setup
To set up Merge replication, you can use the GUI interface from the SQL Server
Enterprise Manager, or you can run SQL Server system stored procedures. The first
way is easier and more understandable.
First of all, you should register the new remote server to be replicated. Because I use
only one server to replicate data, I don't need to make this step. Figure 1 shows
remote server name (the same as the local server name, in this case).
The following screenshot tells how to do that…
Configuring Publisher, Subscriber and Distributor
Now the first thing we have to do is to configure Publishing, Subscribers and
Distribution. We can select the configuration wizard in two ways.
1. By clicking the ‘Configure’ button in the Replication Tab from the SQL Server
Properties Window. The screenshot is added below
2. Another way to get the configuration wizard is through Enterprise Manager.
From Tools menu -> Replication -> Configure Publishing, Subscribers, and
Distribution…
The following is the screenshot of it.
This will be followed by a welcome screen to configure the Publishing and
Distributing. See the below screenshot.
While clicking Next button you will get the window for selecting the Distributor. By
default the wizard will take the Server which you have selected for Replication as the
place to store the Distributor database.
Select the first option and proceed, when you are configuring the distribution in the
same machine. Click Next
This window allows you to customize the settings. Here you can select the path of
the distribution database to be stored. Normally it will be stored inside the data
folder of the SQL Server Installation. If you want to change the path, you can select
first option, if you are not changing the path select the second option (No) and
Proceed.
Click Finish to complete the configuring of the Publishing and Distribution Wizard.
Now SQL Server will configure the following things in your Server.
Once it finishes, you will get the following screens.
Microsoft SQL Server has now created the distribution database, enabled publishing,
and installed the distributor.
Now we can create Publication and Articles.
Before creating Publication and Articles, with the DBScript of Adminv2 and create a
fresh Adminv2 database in the Subscriber machines. The DBScript can be generated
from the SQL Server Enterprise Manager. It is very important that both the Publisher
db and Subscriber db should match in all ways. So while doing any database
modifications in future, think this also.
The following is the screenshot of the menu selection for script generation.
IMPORTANT : For creating Publications, you can use the script attached to it. The
script name is ShopPublication1 & GodownPublication1. It is the script generated
after creating the Publications same as generating the db script.
There are certain things to be noticed before running the Publication Script : ie we
have to set some values according to the situation in the Publication Script. Mainly
we have to set two values
1. Login Name
2. Filter Clause of the articles.
@login = N'SERVER\Admindata' – The ‘SERVER’ part has to be changed
accordingly. Here you have to give the Subscriber name.
@subset_filterclause = N'idshopid = 1' – This is the shop id, which has to be
given according to your need.
If you have more shops, you need to create more Publications. You can create the
publication for another shop as follows.
Copy the Publication script [ShopPublication1] and create a new file.
Rename it to ShopPublication1 to ShopPublication2 in the File name and the values
inside the file with the same name. Change the login name, Server Name and
filterclause condition. For the second one it will be @subset_filterclause = N'idshopid
= 2'. So carefully do that.
If you have godowns, for creating Godown Publications, you can run the
GodownPublication script.
So, if you are running from the Publication script, you can skip the following
‘Creating Publications And Articles’. You can directly go to ‘How to push a
new Subscription’ on Page No 30.
Creating Publications and Articles
Now we are ready to start creating publications and articles. At this stage we have to
tell SQL Server, to which database the publication has to be defined. For this we
have to do the following steps.
Select Tools => Replication => Create and Manage Publications as shown in the
screenshot below
In the above window select the database which you want the publication to be
created. Like in the above picture I have selected Adminv2. Select the database and
click Create Publication. At this point the following window will appear.
Choose the database which you want to publish and Click Next.
Select the Publication Type as “Merge Publication”.
Specify the Subscriber Types. Select “Servers running SQL Server version 7.0”.
Then click Next.
Select the Object Types (like Tables, Stored Procedures and Views) which you want
to publish, and click Next.
It will show some issues which may require some changes at later stages in order
to work as expected. Just click Next.
3. Give Publication Name and click Next.
It will ask to customize the properties of the Publication. Select “Yes, I will define
data filters, enable anonymous subscriptions, or customize other properties”. Then
click Next.
Then, it will ask “How do you want to filter this publication?” Don’t select any thing
here. Just click Next.
Then, it will ask “Whether you want to allow anonymous subscription to this
publication?”. Select “No, allow only named subscriptions”, and click Next.
It will show “Set Snapshot Agent Schedule” dialog box. Change the Snapshot Agent
Schedule as per your requirement, then select “Create the first snapshot
immediately”. And click Next.
Click Finish to create a Publication.
This will give the following windows
Finally, it will show “SQL Server Enterprise Manager successfully created publication
‘pub1’ from database ‘db1’. Just click Close
It will show the dialog box “Create and Manage Publications on respective Server”.
Now go to the respective created Publication and click “Push New Subscription”.
Here onwards you can start Push New Subscription for the newly created
Publication
How to push a new Subscription
Hope you are going to push the new subscription after running the Publication Script.
Or else you can continue from the above window which will be the last window
showed after creating the Publication from SQL Server Enterprise Manager.
Before doing “Push New Subscription”, create new SQL Server Registration for
Subscriber machine in the Publisher machine’s SQL Server Enterprise manager with
SQL Authentication mode. For this, there should be one common SQL login name in
both Publisher and Subscriber machines. Set server roles for this user as System
Administrator, Process Administrator and Bulk Insert Administrators, and give
database access to the respective database for which you want to perform
replication.
Select Replication=>Push Subscriptions to Others... This will open “Push Subscription
Wizard”.
Now you will get a window like the below. When expanding Adminv2 you can see the
Publications you have added to it.
Select the Publication and click the button Push New Subscription. Here I am
selecting ShopPublication1, which I am aiming to connect to the subscriber ABBAS.
Click Next
Now you will get a Subscriber selection window. Select the subscriber and click Next.
The wizard will show the Subscription Database. Click Next. The wizard will now give
you a window where you can select or change the Merge Agent Schedule
If you want to change the schedule you can do it now, later also this can be altered.
Just initialize the subscription, do not start it immediately. We can start it manually
later after setting timeout values.
In the next window you can select priority settings, leave the window as it is and
click next.
Specify whether the Subscription(s) needs to be initialized or not. Select “Yes,
initialize the schema and data” as well as select “Start the Snapshot Agent to begin
the initialization process immediately”, and click Next.
Click Finish to complete the configuring of Pushing new Subscription.
You will get a message window saying that the subscription successfully created at
the subscriber. You can push the remaining Publications to the respective
subscriptions as per your requirement.
Now if you are opening the Enterprise Manager you can see the Publications,
Snapshot Agents and the Merge Agents.
It is very important to note that the Snapshot Agents has to be run once after doing
the above tasks. It is the Merge Agent which is running continuously and doing the
role in Replication.
The following is the screenshot of the available Publications and Merge Agents. If you
click the folder Snapshot Agents, you can see the available Snapshot Agents in the
window pane in the right side of the SQL Server Enterprise Manager.
Let us see what we have to do after this. The first thing we have to do is setting the
timeout for the Snapshot Agents and Merge Agents before running.
So, select the Snapshot Agents folder under the Replication Monitor. Snapshot
Agents will be listed in the right side. Select the agents => Right Click => select
User Profile. Below is the screenshot for that
Click the copy button, you will get a window like this
Create an User Profile like this, give LoginTimout a big value or else it may fail, if the
value is low. Click OK and Apply it. Like this do the same thing for other Snapshots
also.
Once you finish this you can select the Agent Properties of the Snapshot Agents, as
you selected Agent Profile. It is above the Agent Profile in the menu. Select the
Schedule Tab, select the schedule, click Edit button. Change the option to One time.
Because, the Snapshot Agents need to run only one time. The following is the
screenshot of this
Apply the changes and click OK. Make sure that the option button selection is in the
newly created profile. Normally it wont come by default, when you create one new
profile.
Do the same for all Snapshot Agents. When we create one User Profile it will be
automatically added to all Snapshot Agents. Just Select it rightly.
Now we have to set the User Profile for Merge Agents. Inside the Replication Monitor
down to the Snapshot Agents, select the Merge Agents. The available Merge agents
will be displayed in the right side pane. Right click merge agent one by one and set
the User Profile and Schedule.
Apply the changes and click OK. Make sure that the selected profile is newly created
User Profile.
The schedule you can set according to your convenience to 5 min or 15 min or ½ an
hour. According to the schedule, the Merge Agents will be working and merging the
data from and to the Subscriber.
Refresh Rate & Settings
When we right click on a Snapshot Agent, we can see Refresh Rates And Settings
menu. Select that and tick the checkboxes as above. By doing this the replication
monitor will be refreshed frequently, and you can view the things happening inside
the pane in ‘Last Action’ column.
After setting this we have to run the Snapshot Agents one by one. So the articles will
be generated at the Subscriber. For this right click the Snapshot Agents and click
Start. See the following screenshot.
If you have selected Refresh Rate and Settings, you can see the details in the right
side pane. This process will create Replication Triggers and prepare the tables which
we mentioned inside the Publication for Replication. This is one time action. Once it is
successfully done you don’t need to redo again.
The particular task is redone again, when the shop server fails and we need to push
the shop data from the server to the shop again, after installing a new SQL Server.
Finally you will get a screen like this.
After finishing the Snapshot Agent, you can run the Merge Agent of the same
publication. Likewise proceed with next Snapshots… Sometimes when you finish one
Snapshot, the Merge Agent associated with this will automatically start pushing. If
so, wait until it finishes.
Another important thing to be noted that when running the Snapshot of Shop
Publication2, if the Merge Agent of Shop Publication1 is running it will generate an
error. So, make sure that while running the Snapshot Agents no other Agents are
running.
After finishing the Snapshot pane will look like the above screenshot.
The count 190 depends on the number of articles you specify inside the Publication
Script.
Finally you will get a window like this..
This window tells us that Merge Agent is Succeeded & No data needed to be merged
for the Merge Agent. By this time, all the data from the Server will be Replicated to
the subscriber according to the filter clause. That is the final stage of Replication.
When the transactions works, you can see the last action part get updated. See the
below screenshot.
It shows Merged 8 data changes (0 inserts,8 updates, 0 conflicts).
Please note the following things after Pushing the Subscriptions
1. Add all the shop prefixes. If it is a godown add the godown prefixes.
2. Remove data from the table losSettings [while pushing the data will be loaded
to this table, but it will again loaded when the shop server is login for the first
time. This will cause conflicts. So remove the data pushed in this table].
Other Related things.
When you double click a Merge Agent, you will get a window like this
This tells us the last sessions done by the Merge Agent. In short we can say that
Merge Agent history. This can also be taken by Right Clicking an Agent.
If you select a particular row and click the button Session Details, you will get the
details of that particular session, and you can see what caused the session to retry
or fail. When the session retries, it will show a symbol, like that you can see in the
above screenshot. When a session fails, you can see the red color error symbol. The
following is the screenshot of the Session Details window.
When you select an action message, Error Details button will be enabled, and when
you click that button you will get a detailed description of the action. The following is
the screenshot of that
See the selected part is the error message, that was invoked by the value in the Last
Command section.
It is possible to email such errors, or sent messages to network systems, when a
Merge Agent fails, or an error happens. It can be set in the notification Tab of the
Agent Properties Window.
Replication Performance Tuning Tips:






By distributing partitions of data to different Subscribers.
When running SQL Server replication on a dedicated server, consider setting
the minimum memory amount for SQL Server to use from the default value of
0 to a value closer to what SQL Server normally uses.
Don’t publish more data than you need. Try to use Row filter and Column
filter options wherever possible as explained above.
Avoid creating triggers on tables that contain subscribed data.
Applications that are updated frequently are not good candidates for database
replication.
For best performance, avoid replicating columns in your publications that
include TEXT, NTEXT or IMAGE data types.
Prepared By : Aneesh YK
Implementation Manager – [2005-2006]