Important Terminologies: What is Replication? Replication is the process where data is copied between databases on the same server or different servers connected by LANs, WANs, or the Internet. Microsoft SQL Server replication uses a publisher, distributor and subscriber metaphor. What is Publisher? Publisher is the server or database that sends its data to another server or database. What is Subscriber? Subscriber is the server or database that receives data from another server or database. What is Distributor? Distributor is the server that manages the flow of data through the replication system. This server contains the distribution database. What is Publisher? Publisher contains publication/publications. Publication is a collection of one or more articles that is sent to a subscriber server or database. What is Article? An Article is a unit of replication and can be a table or a subset of a table. What is Subscription? Subscription is the group of data that a server or database will receive. Subscription Types: There are push and pull subscriptions. What is Push subscription? Push subscription is subscription when the publishing server will periodically push transactions out to the subscribing server or database. What is Pull subscription? 1 of 38
Pull subscription is subscription when the subscribing server will periodically connect to the distribution database and pull information. What is Distribution database? 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 other 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. 2 of 38
Central publisher with remote distributor: Chapter-15 In this topology, distribution database resides on another server than publisher. This topology uses 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 unused replication topologies, because it has only single point of failure (on the single server with central distributor), and if distributor's server fail, 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 subscriber, and then this subscriber publish data to any number of other subscribers. This is useful when a Publisher should send data to Subscribers over a slow or expensive communications link. 3 of 38
Replication types Microsoft SQL Server supports the following replication types: Snapshot Replication Transactional Replication Merge Replication What is Snapshot Replication? Snapshot replication is a simplest type of replication. With this kind of replication, all replicated data (replica) will be copied from the Publisher database to Subscriber(s) database on a periodic basis. Snapshot replication is best used as a method for replicating data that changes infrequently and when the size of replicated data is not very large. What is Transactional Replication? With Transactional replication, SQL Server captures all changes that were made in the articles and stores INSERT, UPDATE, and DELETE statements in the distribution database. This changes 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 the replicated data on the Publisher and on the Subscriber. What is Merge Replication? Merge replication is a most complicated replication type. It allows making autonomous changes to replicated data on the Publisher and on the Subscriber. 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 the replicated data on the Publisher and on the Subscriber. Replication agents: Microsoft SQL Server supports the following replication agents: 4 of 38
Snapshot Agent Log Reader Agent Merge Agent Distribution Agent 5 of 38
What is Snapshot Agent? The Snapshot Agent is a replication agent that makes 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. What is Log Reader Agent? 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. What is Distribution Agent? 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. What is Merge Agent? 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. 6 of 38
-::- Setting Up Transactional Replication -::- Conditions for Transactional Replication: Following are the important things to consider before setting up a transactional replication: 1. Microsoft SQL Desktop Edition supports only subscriptions to transaction replication. So, you must use Microsoft SQL Standard, Enterprise or Small Business Server (SBS) editions to publish transaction replication. So, for publish transaction replication you should have Windows NT Server, Windows NT Server Enterprise Edition or Windows NT Small Business Server (on Windows NT WorkStation and Windows 9x you can install only SQL Server Desktop Edition). 2. The Localsystem account has no access to shares on the network as it isn't an authenticated network account. So, you must change the account the MSSQLServer and SQLServerAgent services runs under to an account with the Windows NT administrator's rights besides Localsystem account. 3. Only members of the sysadmin fixed server role can set up and configure replication, so if you have not these rights, you can not set up replication. 4. You must uncheck trunc log on chkpt option, to set up transactional replication. 5. Allocate adequate log space for each database that will be published in transactional replication. 6. Allocate adequate disk space for the distribution database. 7. Ensure the server that is being replicated to, is defined as a remote server. Necessary connection: 1. Check TCP/IP by using ping utility. 2. Check odbc connection by using odbcping utility. Syntax of odbcping utility: odbcping [-S Server -D DSN] [-U Login Id] [-P Password] If you have received the message like below, the SQL Server works okay: Setting Up Transactional Replication: Here, we will use two servers: TTISPRO-ST-01 as publisher and distributor and TTISPRO-ST- 04 as subscriber. We will use transactional replication with push subscription. Register new remote server in which will be replicated. 7 of 38
8 of 38
Enter the name of remote server and specify Remote Login Mapping: 9 of 38
If you have made all correctly, you see a screen like following: 10 of 38
Select Tools -> Replication -> Configure Publishing and Subscribers: 11 of 38
This will launch the Configure Publishing and Distribution Wizard as follows: Select the Next button to create the Distributor. 12 of 38
Now, you can choose the default settings or set the distribution database name and location, enable other Publishers, or set other settings. Click the Next button. 13 of 38
Click the Finish button from the figure below: 14 of 38
Now SQL Server starts configuring. See figure below: Now, SQL Server creates the distribution database, enables publishing, and setting up the distributor: 15 of 38
Because we installed TTISPRO-ST-01 as Distributor, the Replication monitor has been added to the console tree on the TTISPRO-ST-01 server. The following figure confirms it. Now click Close. 16 of 38
Now, we are ready to start creating publications and articles. Select Tools -> Replication -> Create and Manage Publications: You will see Create and Manage Publications dialog box: Choose SMS2KWIN03 database and click the Create Publication button. 17 of 38
This will launch the Create Publication wizard. 18 of 38
Select Transactional publication from above screen and click Next button. 19 of 38
You can allow immediate-updating subscriptions on this step. If you choose this option then all changes will be applied at the Subscriber and Publisher simultaneously. 20 of 38
Choose Subscriber types on this step. If all subscribers are Microsoft SQL Server subscribers, choose the first option. 21 of 38
Select tables or stored procedures to publish and click Next button. 22 of 38
23 of 38
Choose publication name and description on this step. You can define data filters or set another options on this step. 24 of 38
Click Finish button to create the publication. 25 of 38
If publication was created successfully, you will receive the above message. 26 of 38
Create new push subscription now. Chapter-15 Click Next button. 27 of 38
Choose subscribers. Click Next button. 28 of 38
Choose destination database. It's pubs database on the TTISPRO-ST-04 server. If you want to have continuous replication that will send the data as soon as possible, you can choose continuously option. Otherwise, choose schedule option. Select the Continuously option and click the Next button. 29 of 38
Initialize subscription if it's needed. Click Next button. 30 of 38
Click Finish button to create the subscription. Now, you will receive the following: 31 of 38
32 of 38
Data Validation for Transactional Replication: Microsoft SQL Server allows you to validate transactional replication. You can specify rowcount only validation or rowcount and checksum validation of the article's data. When you choose rowcount only validation, the SQL Server calculates a rowcount at the publisher then compares the result with the rowcount at the subscriber to verify that the data is in synchronization. When you choose rowcount and checksum validation, the SQL Server calculates a rowcount and checksum at the publisher then compares the result with the rowcount and checksum at the subscriber. So, if the size of replicated data is very large, you can perform a rowcount only validation. The validation process works in the latent mode, i.e. it does not interrupt transactions on the publisher and the current replication process will not be stopped. You can use the sp_publication_validation stored procedure to validate data for transactional replication. This stored procedure validates the data associated with each article by calling sp_article_validation (after the articles associated with a publication have been activated). The sp_article_validation stored procedure invokes sp_table_validation stored procedure, which calculates the number of lines and the control sum of the published table. Then the sp_article_validation system stored procedure inserts a call of sp_table_validation directly into a transaction log at the publisher. After that Distribution Agent sends a call of the sp_table_validation to the subscribers and checks the data at the subscriber with the data at the publisher. The Distribution Agent raises the 20574 system message or the 20575 system message, if the validation fails or if the validation passes accordingly. The Distribution Agent will replicate changes to a subscriber even if the validation shows that the subscriber is out of synchronization. You can check the Windows NT or Windows 2000 Application log to see validation's result (20574 and 20575 system messages will be written into Application log). You can also configure the Replication Alert on the 20574 and 20575 system messages to send E-Mail, Pager, or Network notification to administrator that validation fails or passes. Restrictions Rowcount only validation is available only for SQL Server 6.x or later subscribers, and rowcount and checksum validation is available only for SQL Server 7.0/2000 and above subscribers. The checksum validation cannot be used when the base table has been filtered vertically, but it can be used when the table has been filtered horizontally, because the checksum is calculated on the entire row. The checksum algorithm is a 32-bit redundancy check (CRC), calculates checksum value for all columns, ignoring data in text and image columns. 33 of 38
The tables at the publisher and at the subscribers must have identical structure (the same columns in the same order, the same data types and lengths, and the same NULL/NOT NULL property). It is necessary for correct calculation of the control sum. SQL Server uses bcp utility to copy data from publisher to subscribers. This utility can work in native or in character mode. If you use columns with float data, and your application has heterogeneous subscribers, the bcp utility will work in character mode and checksum on publisher and subscriber will not equal. You cannot use rowcount and checksum validation in this case, only rowcount validation. You should stop the MSDTC service at the Publisher during validation (to ensure that the values at the Subscriber and Publisher do not change during validation process). Example Here, I want to illustrate how you can validate Transactional replication step by step. First of all, you should enable the following replication alerts: 1. Subscriber has failed data validation 2. Subscriber has passed data validation These alerts generate 20574 and 20575 system messages accordingly. 34 of 38
Then you will see the following: Chapter-15 Check Enabled box and press Apply button. Choose Yes button. Make the same actions for alert Subscriber has passed data validation. 35 of 38
36 of 38
Then you will see the following: Chapter-15 Check Enabled box and press Apply button. Then you will see the following: Choose Yes. You can validate your data on a regular schedule by creating a Transact-SQL job or you can run sp_publication_validation or sp_article_validation from the Query Analyzer. 37 of 38
Start Snapshot Agent. If everything is okay, you will receive the 20575 message. This alert will be written into the Windows NT/Windows 2000 Application log. 38 of 38