Introduction In this article, I want to tell you about some general Microsoft SQL Server replication's topics: replication

topologies, replication types, replication agents; and about Snapshot replication: how to check necessary conditions for this replication type, how to backup and restore databases participated in this replication scenario, and how to setting up Snapshot replication step by step. Because it's only test example, I used only one server to replicate data: Publisher, Subscriber and Distributor databases were resided on the same machine. General concepts Replication is the process whereby 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. Publisher is the server or database that sends its data to another server or database. Subscriber is the server or database that receives data from another server or database. Distributor is the server that manages the flow of data through the replication system. This server contains the distribution database. Publisher contains publication/publications. Publication is a collection of one or more articles that is sent to a subscriber server or database. Article is the basic unit of replication and can be a table or a subset of a table. Subscription is the group of data that a server or database will receive. There are push and pull subscriptions. Push subscription is subscription when the publishing server will periodically push transactions out to the subscribing server or database. Pull subscription is subscription when the subscribing server will periodically connect to the distribution database and pull information. 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, 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 will 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.

Replication types Microsoft SQL Server 7.0/2000 supports the following replication types:

Snapshot Transactional Merge

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/Subscribers 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. 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. Merge replication is a most difficult 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 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 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. 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. Checking necessary conditions Check the following before setting up Snapshot replication: 1. The Localsystem account has no access to shares on the network as it isn't an authenticated network account. So, if you want to setting up replication you must change the account the MSSQLServer and SQLServerAgent services runs under to a 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 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. Because 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 setting up and configure replication, so if you have not these rights, you cannot setting up replication. 3. Don't forgive to start SQLServerAgent service (and MSSQLServer service, of course). 4. You should allocate adequate disk space in the snapshot folder. 5. You should allocate adequate disk space for the distribution database.

6. You should ensure the server that is being replicated to, is defined as a remote server. Step by step example In this example, I will use only one server to replicate data: Publisher, Subscriber and Distributor databases will be resided on the same machine. I will use Snapshot replication with push subscription. To setting up Snapshot replication, you can use GUI interface (from the SQL Server Enterprise Manager), or you can run SQL Server system stored procedures. The first way is much easy and much understandably, so I will use it. First of all, you should register the new remote server in which will 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).

Figure 1. In this example, I will replicate data from the pubs database into pubs_copy database.

Figure 2. Select Tools => Replication => Configure Publishing, Subscribers, and Distribution... as shown in Figure 3.

Figure 3.

This will launch the Configure Publishing and Distribution Wizard, as shown in Figure 4.

Figure 4. Select the Next button to create the Distributor, as shown in Figure 5.

Figure 5. Here you can configure SQLServerAgent service to start automatically when the computer is started. Check Yes, configure the SQL Server Agent service to start automatically and click the Next button, as shown in Figure 6.

Figure 6. Specify snapshot folder using a network path and click the Next button, as shown in Figure 7.

Figure 7. Now you can customize the publishing and distribution settings, or you can choose the default settings. Check No, use the following default settings and click the Next button, as shown in Figure 8.

Figure 8. Click the Finish button, as shown in Figure 9.

Figure 9. Microsoft SQL Server created the distribution database, enabled publishing, and installed the distributor. Once completed, you should see Figure 10.

Figure 10. Click OK button and see Figure 11. As we installed CHIGRIK as Distributor, so Replication monitor has been added to the console tree on CHIGRIK server. Click Close button.

Figure 11. Now we are ready to start creating publications and articles. Select Tools => Replication => Create and Manage Publications as shown in Figure 12.

Figure 12. You will see Create and Manage Publications dialog box, as shown in Figure 13. Choose pubs database and click the Create Publication button.

Figure 13. The Create Publication wizard will be launch. Click the Next button, as shown in Figure 14.

10

Figure 14. Choose the pubs database and click the Next button, as shown in Figure 15.

Figure 15. Select Snapshot publication and click the Next button, as shown in Figure 16.

11

Figure 16. Select all of the types of Subscribers that you expect to subscribe to this publication and click the Next button, as shown in Figure 17.

Figure 17. Choose authors table to publish as article and click the Next button, as shown in Figure 18.

12

Figure 18. Specify pubs_article as the publication name and click the Next button, as shown in Figure 19.

Figure 19. You can specify data filters on this step, but in this example, we don't use any data filters. Check No, create the publication as specified and click the Next button, as shown in Figure 20.

13

Figure 20. Click the Finish button to create the publication, as shown in Figure 21.

Figure 21. Now the 'pubs_article' publication was created, so click the Close button, as shown in Figure 22.

14

Figure 22. Now you can create new subscription. Click the Push New Subscription button, as shown in Figure 23.

Figure 23. This will launch the Push Subscription wizard shown in Figure 24. Click the Next button.

15

Figure 24. Select CHIGRIK to select all subscribers in that group and click the Next button, as shown in Figure 25.

Figure 25. Select pubs_copy database as the subscription database and click the Next button, as shown in Figure 26.

16

Figure 26. Specify how frequently Distribution Agent updates the subscription (in this example, every 1 day(s), every 20 minute(s) between 9:00:00 and 18:00:00) and click the Next button, as shown in Figure 27.

Figure 27. Check Start the Snapshot Agent to begin the initialization process immediately and click the Next button, as shown in Figure 28.

17

Figure 28. Click the Next button, as shown in Figure 29.

Figure 29. Click the Finish button to subscribe with the options you specified on the previous steps, as shown in Figure 30.

18

Figure 30. Click the Close button, as shown in Figure 31.

Figure 31. Click the Close button to close the Create and Manage Publication dialog, as shown in Figure 23. Note. On the last step we got the following message: The subscription at Subscriber 'CHIGRIK' cannot be initialized

19

immediately because the snapshot for this publication is not yet available. To initialize the subscription, start the Distribution Agent after the snapshot is available. To work around it, you should start the Distribution Agent after the snapshot is available. See Figure 32.

Figure 32. Backup and restore strategies The backup and restore strategies are differ for each replication types. Here, I want to describe the backup and restore strategies for the Snapshot replication. There are four main strategies for backing up and restoring Snapshot replication:

Backup Publisher, master and model databases. Backup Publisher, Distributor, master and model databases. Backup Publisher, Subscriber(s), master and model databases. Backup Publisher, Distributor, Subscriber(s), master and model databases.

Backing up Publisher, master and model databases is a simplest strategy. This strategy has its own advantages and disadvantages. The advantages are that it requires the least amount of storage resources and does not require coordinating the backup with the backup of any other servers. The main disadvantage of this strategy is that you may need to setup replication from the beginning in the event of a Publisher or Distributor failure. With this strategy, you should backup publication database after changing existing publications or after the new publications were added. Backing up Publisher, Distributor, master and model databases is a more frequently used strategy, than the first one, because in this case you don't need to reestablish replication in the event of a Publisher or Distributor failure. The main disadvantage of this strategy is that you should backup Publisher and Distributor's databases simultaneously (or as closely as possible). It also requires more computing and storage resources than the first way. Backing up Publisher, Subscriber(s), master and model databases let you to reduce the amount of time required to recover a Subscriber(s) by avoiding the need to reinitialize the Subscriber(s) with a new snapshot, but in the event of a Distributor failure, you should setup replication from the beginning. Backup Publisher, Distributor, Subscriber(s), master and model databases is a most complex backup strategy. The main advantage of this strategy is that in the event of a Publisher, Distributor or Subscriber(s) failure, you can quickly restore fail database without setting up replication from the beginning. The disadvantage of this strategy is that you should backup Publisher and Distributor's databases simultaneously (or as closely as possible), and this strategy requires most computing and storage resources. For each strategy, you should backup msdb and master databases on the Publisher, Distributor and Subscriber(s). msdb database is

20

used by SQL Server Agent for scheduling alerts and jobs (it contains also snapshot jobs), and master database is a main system database contains entries for each Subscriber(s), each login account, about system configuration settings and so on.

General concepts Replication is the process whereby 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. Publisher is the server or database that sends its data to another server or database. Subscriber is the server or database that receives data from another server or database. Distributor is the server that manages the flow of data through the replication system. This server contains the distribution database. Publisher contains publication/publications. Publication is a collection of one or more articles that is sent to a subscriber server or database. Article is the basic unit of replication and can be a table or a subset of a table. Subscription is the group of data that a server or database will receive. There are push and pull subscriptions. Push subscription is subscription when the publishing server will periodically push transactions out to the subscribing server or database. Pull subscription is subscription when the subscribing server will periodically connect to the distribution database and pull information. 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. 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.

21

Central publisher with remote distributor 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 will 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.

Checking necessary conditions

22

Check the following before setting up transactional replication: 1. Remember that 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, if you want to setting up replication you should change the account the MSSQLServer and SQLServerAgent services runs under to an account with the Windows NT administrator's rights. 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, if you want 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. Checking connect 1. Check TCP/IP by using ping utility. 2. Check odbc connection by using odbcping utility. This is the 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: CONNECTED TO SQL SERVER ODBC SQL Server Driver Version: 03.70.0623 SQL Server Version: Microsoft SQL Server 7.00 - 7.00.623 (Intel X86) Nov 23 1998 21:08:09 Copyright (c) 1988-1998 Microsoft Corporation Standard Edition on Windows NT 4.0 (Build 1381: Service Pack 4) Example In this example, I will use two servers: CHIGRIK_A_U - publisher and distributor and MAKSIMUK_I_L - subscriber. I will use transactional replication with push subscription. Register new remote server in which will be replicated.

23

Enter the name of remote server and specify Remote Login Mapping:

24

If you have made all correctly, you receive the following:

Select Tools -> Replication -> Configure Publishing and Subscribers:

This will launch the Configure Publishing and Distribution Wizard:

25

Select the Next button to create the Distributor:

Now, you can choose the default settings or set the distribution database name and location, enable other Publishers, or set another settings. Click the Next button.

26

Click the Finish button.

Now, SQL Server creates the distribution database, enables publishing, and setting up the distributor:

27

Because we installed CHIGRIK_A_U as Distributor, the Replication monitor has been added to the console tree on the CHIGRIK_A_U server.

Now, we are ready to start creating publications and articles. Select Tools -> Replication -> Create and Manage Publications:

28

You will see Create and Manage Publications dialog box:

Choose pubs database and click the Create Publication button.

This will launch the Create Publication wizard.

29

Select Transactional publication and click Next button.

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.

30

Choose Subscriber types on this step. If all subscribers are Microsoft SQL Server subscribers, choose the first option.

Select tables or stored procedures to publish and click Next button.

31

Choose publication name and description on this step.

You can define data filters or set another options on this step.

32

Click Finish button to create the publication.

If publication was created successfully, you will receive the above message.

33

Create new push subscription now.

Click Next button.

Choose subscribers. Click Next button.

34

Choose destination database. It's pubs database on the MAKSIMUK_I_L 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.

35

Initialize subscription if it's needed.

Click Next button.

36

Click Finish button to create the subscription. Now, you will receive the following:

Introduction In this article, I want to tell you about some general Microsoft SQL Server replication's topics: replication topologies, replication types, replication agents; and about Merge replication: how to check necessary conditions for this replication type, how to backup and restore

37

databases participated in this replication scenario, and how to setting up Merge replication step by step. Because it's only test example, I used only one server to replicate data: Publisher, Subscriber and Distributor databases were resided on the same machine. General concepts Replication is the process whereby 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. Publisher is the server or database that sends its data to another server or database. Subscriber is the server or database that receives data from another server or database. Distributor is the server that manages the flow of data through the replication system. This server contains the distribution database. Publisher contains publication/publications. Publication is a collection of one or more articles that is sent to a subscriber server or database. Article is the basic unit of replication and can be a table or a subset of a table. Subscription is the group of data that a server or database will receive. There are push and pull subscriptions. Push subscription is subscription when the publishing server will periodically push transactions out to the subscribing server or database. Pull subscription is subscription when the subscribing server will periodically connect to the distribution database and pull information. 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(s) is/are configured as Subscriber(s).

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.

38

Central publisher with remote distributor 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 will 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.

Replication types Microsoft SQL Server 7.0/2000 supports the following replication types:

39

Snapshot Transactional Merge

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. 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. 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 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 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. 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. Checking necessary conditions 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. So, if you want to setting up replication you must change the account the MSSQLServer and SQLServerAgent services runs under to a 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 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. Because 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 setting up and configure replication, so if you have not these rights, you cannot setting up replication. 3. Don't forgive to start SQLServerAgent service (and MSSQLServer service, of course). 4. You should allocate adequate disk space for the distribution database. 5. You should allocate adequate disk space for the publisher and subscriber's databases. SQL Server 7.0/2000 uses 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 the 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.

40

7. You should ensure the server that is being replicated to, is defined as a remote server. Step by step example In this example, I will use only one server to replicate data: Publisher, Subscriber and Distributor databases will be resided on the same machine. I will use Merge replication with push subscription. To setting up Merge replication, you can use GUI interface (from the SQL Server Enterprise Manager), or you can run SQL Server system stored procedures. The first way is much easy and much understandably, so I will use it. First of all, you should register the new remote server in which will 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).

Figure 1. In this example, I will replicate data from the pubs database into pubs_copy database.

41

Figure 2. Select Tools => Replication => Configure Publishing, Subscribers, and Distribution... as shown in Figure 3.

Figure 3. This will launch the Configure Publishing and Distribution Wizard, as shown in Figure 4.

42

Figure 4. Click the Next button to create the Distributor, as shown in Figure 5.

Figure 5. Here you can configure SQLServerAgent service to start automatically when the computer is started. Check Yes, configure the SQL Server Agent service to start automatically and click the Next button, as shown in Figure 6.

43

Figure 6. Specify snapshot folder using a network path and click the Next button, as shown in Figure 7.

Figure 7. Now you can customize the publishing and distribution settings, or you can choose the default settings. Check No, use the following default settings and click the Next button, as shown in Figure 8.

44

Figure 8. Click the Finish button, as shown in Figure 9.

Figure 9. Microsoft SQL Server created the distribution database, enabled publishing, and installed the distributor. Once completed, you should see Figure 10.

45

Figure 10. Click OK button and see Figure 11. As we installed CHIGRIK\SQL2000 as Distributor, so Replication monitor has been added to the console tree on CHIGRIK\SQL2000 server. Click Close button.

Figure 11. Now we are ready to start creating publications and articles. Select Tools => Replication => Create and Manage Publications as shown in Figure 12.

46

Figure 12. You will see Create and Manage Publications dialog box, as shown in Figure 13. Choose pubs database and click the Create Publication button.

Figure 13. The Create Publication wizard will be launch. Click the Next button, as shown in Figure 14.

47

Figure 14. Choose the pubs database and click the Next button, as shown in Figure 15.

Figure 15. Select Merge publication and click the Next button, as shown in Figure 16.

48

Figure 16. Select all of the types of Subscribers that you expect to subscribe to this publication and click the Next button, as shown in Figure 17.

Figure 17. Check Publish All checkbox to publish all tables from the pubs database and click the Next button, as shown in Figure 18.

49

Figure 18. Click the Next button, as shown in Figure 19, to add uniqueidentifier columns in all tables in the pubs database and set NOT FOR REPLICATION option to the IDENTITY column of the jobs table.

Figure 19. Specify pubs_article as the publication name and click the Next button, as shown in Figure 20.

50

Figure 20. You can specify data filters on this step, but in this example, we don't use any data filters. Check No, create the publication as specified and click the Next button, as shown in Figure 21.

Figure 21. Click the Finish button to create the publication, as shown in Figure 22.

51

Figure 22. Now the 'pubs_article' publication was created, so click the Close button, as shown in Figure 23.

Figure 23. Now you can create new subscription. Click the Push New Subscription button, as shown in Figure 24.

52

Figure 24. This will launch the Push Subscription wizard shown in Figure 25. Click the Next button.

Figure 25. Click on the SQL Server Group to select all subscribers in the CHIGRIK and CHIGRIK\SQL2000 groups and click the Next button, as shown in Figure 26.

53

Figure 26. Select pubs_copy database as the subscription database and click the Next button, as shown in Figure 27.

Figure 27. Specify how frequently Distribution Agent will update the subscription (in this example, every 1 day(s), every 30 minute(s) between 9:00:00 and 18:00:00) and click the Next button, as shown in Figure 28.

54

Figure 28. Check Start the Merge Agent to initialize the subscription immediately and click the Next button, as shown in Figure 29.

Figure 29. Now you can set the subscription priority, which helps decide the winner of conflicting data changes. Check Use the Publisher as a proxy for the Subscriber when resolving conflicts and click the Next button, as shown in Figure 30.

55

Figure 30. Click the Next button, as shown in Figure 31.

Figure 31. Click the Finish button to subscribe with the options you specified on the previous steps, as shown in Figure 32.

56

Figure 32. Click the Close button, as shown in Figure 33.

Figure 33. Click the Close button to close the Create and Manage Publication dialog, as shown in Figure 24. The last step of the setting up Merge replication should be creation a current script of your replication settings. It can be useful to help recover your replication settings in the event of server failure.

57

Select Tools => Replication => Generate SQL Script... as shown in Figure 34.

Figure 34. Backup and restore strategies The backup and restore strategies are differ for each replication types. Here, I want to describe the backup and restore strategies for the Merge replication. Because Merge replication is more complicated than Snapshot or Transactional replication, and usually used when you want to update data on both publisher and subscribers, so you should plan backup and restore strategies more detail and attentive. There are four main strategies for backing up and restoring Merge replication:

Backup Publisher, master and model databases. Backup Publisher, Distributor, master and model databases. Backup Publisher, Subscriber(s), master and model databases. Backup Publisher, Distributor, Subscriber(s), master and model databases.

Backing up Publisher, master and model databases is a simplest strategy. This strategy has its own advantages and disadvantages. The advantages are that it requires the least amount of storage resources and does not require coordinating the backup with the backup of any other servers. The main disadvantage of this strategy is that you may need to setup replication from the beginning in the event of a Publisher or Distributor failure. With this strategy, you should backup publication database after changing existing publications, or after the new publications were added, or whenever changes are made to a replicated objects schema (for example, adding or dropping a column). Backing up Publisher, Distributor, master and model databases is a rarely used strategy, than the first one, because in most cases, it is not necessary to restore a distribution database when restoring a publication database backup for merge publications. It is because the distribution database does not store any data used in change tracking and it does not provide temporary storage of merge replication changes. The main disadvantage of this strategy is that you should backup Publisher and Distributor's databases simultaneously (or as closely as possible). It also requires more computing and storage resources than the first way. Backing up Publisher, Subscriber(s), master and model databases is used when some changes were made on Subscriber(s) and you need these changes to be synchronized with the publication database.

58

Backup Publisher, Distributor, Subscriber(s), master and model databases is a most complex backup strategy. The main advantage of this strategy is that in the event of a Publisher, Distributor or Subscriber(s) failure, you can quickly restore fail database without setting up replication from the beginning. The disadvantage of this strategy is that you should backup Publisher and Distributor's databases simultaneously (or as closely as possible), and this strategy requires most computing and storage resources. For each strategy, you should backup msdb and master databases on the Publisher, Distributor and Subscriber(s). msdb database is used by SQL Server Agent for scheduling alerts and jobs, and master database is a main system database contains entries for each Subscriber(s), each login account, about system configuration settings and so on. Note. It is strongly recommended that you make and keep a current script of your replication settings. It can be useful to help recover your replication settings in the event of server failure.

59

Tips for Performance Tuning SQL Server Replication: General Replication Performance Tips

If your current SQL Server is overwhelmed with work and performance is suffering, one option to move part of its workload onto one or more additional SQL Servers using replication. Replication allows you to "scale out" your SQL Server by distributing the processing load over multiple servers. For example, you might want to consider moving your reporting function from the main (transaction server) to another server (reporting server). This task is relatively easily accomplished by implementing transactional replication. Replication offers many opportunities to scale out your current SQL Server, helping to boost the overall performance of your SQL Server-based applications. [6.5, 7.0, 2000, 2005] Updated 8-5-2005 ***** If you plan is to use replication as part of your SQL Server-based application, and your goal is high scalability and performance, then this factor should be considered when the database is first designed. The fact that you will be using replication, and the type of replication you plan to use, can directly affect how your databases should be designed. In addition, using replication requires a different hardware strategy, which means you also have to plan for this. [6.5, 7.0, 2000, 2005] Updated 8-5-2005 ***** For optimum replication performance, consider these hardware suggestions for servers involved in replication:

Use multiple CPUs. Add additional RAM (besides what you need for using SQL Server without using replication). If you need maximum performance for your transactional or merge replication, you should place the log of every database you want replicated on it own separate disk array. The transaction log is used heavily during transactional and merge replication, and the more you can isolate disk I/O for these files, the higher the performance. Connect all SQL Servers involved in replication using high-speed network connections and switches. Ideally, the distribution component of replication should be on its own dedicated server, not located on the server running the publishing or subscribing components of replication.

[6.5, 7.0, 2000, 2005] Updated 8-5-2005 ***** Don't publish more data than you need, whether you are talking about tables, rows, or columns in a table. You can use vertical and/or horizontal filtering to prevent specific rows or columns of a table from being published. If your tables include columns with IMAGE, NTEXT, or TEXT columns, you should seriously consider filtering out these columns (vertical filtering) because these data types can greatly slow down replication [6.5, 7.0, 2000] Updated 8-3-2003 ***** If close to real-time replication is not required, then don't use continuous replication. Instead, schedule replication to occur at regular intervals, such as once an hour, or every four hours. This reduces unnecessary server overhead. [6.5, 7.0, 2000] Updated 917-2004 ***** When creating the distribution database and its log, don't take the defaults for the location of the database. Instead, manually

60

specify that the log and database be placed on appropriate disk arrays. For best performance, consider putting the distribution database on a RAID 1 or RAID 10 disk array (RAID 5 is not ideal because of the many writes produced by replication), and putting the database log file on its own dedicated RAID 1 disk array. [6.5, 7.0, 2000] Updated 9-17-2004 ***** If the distribution and publishing components of replication have to be on the same server (because of resource considerations), and this server is reaching its performance capacity, then use Pull Subscriptions instead of Push Subscriptions. This will offload some of the work to the subscribing servers. Of course, this assumes the subscribing servers have the resources to do this. [7.0, 2000] Updated 9-17-2004 ***** When creating a publication, SQL Server gives you the ability to specify if one or more of the subscribers will be Microsoft Jet 4.0 databases. If you need this feature, then turn it on. But if you will not have any Microsoft Jet 4.0 subscribers, then don't select this option. What happens when you select this is option is that the Snapshot Agent will use BCP character format, not the faster BCP native format, when running. This also means that any SQL Server subscribers will have to go through extra work translating the BCP character format when it receives the publication, which causes a slight performance hit. [7.0, 2000] Updated 9-17-2004 ***** For best performance, avoid replicating columns in your publications that include TEXT, NTEXT or IMAGE data types. These data types require more overhead than standard data types. [7.0, 2000] Updated 9-17-2004 ***** If you are filtering the data on the publisher before it gets to any of the subscribers, be sure that the column or columns you are filtering on have an appropriate index. If not, then SQL Server will perform table scan to filter the data, putting an increased load on the publisher and reducing performance. [6.5, 7.0, 2000] Updated 9-17-2004 ***** If the replication load is very heavy between the publisher and the distributor, or between the distributor and the subscriber(s), and each of these is on their own dedicated SQL Server, and each are connected by a fast LAN connection, and the latency among the servers is longer that you prefer, consider this option. Instead of using public network connections between each of the servers, use a dedicated private network instead. This can be accomplished by adding an additional NIC to each server, and connecting them using a private hub, switch, or cross-over cable. This technique will boost performance because data replication no longer has to compete with all of the data already traveling on your public network. To ensure the highest performance, use 100Mbs or 1Gbs NICs and matching connection hardware and cable. [6.5, 7.0, 2000] Updated 9-17-2004 ***** When you first click on the Replication Monitor group in Enterprise Manager, after having installed Replication on your server, you see a message asking you if you want to enable polling for Replication Monitor. What this means is that the replication agent status information, found in the Replication Monitor group in Enterprise Manager, will automatically be refreshed periodically if you answer Yes, or it won't be automatically refreshed if you answer No. If you answer Yes, then you will see another screen that allows you to specify how long the refresh interval will be. As you might imagine, if you answer Yes, SQL Server will have to incur some additional overhead to automatically refresh the status information. For the most part, the default 10 seconds refresh interval won't produce a significant amount of overhead, and it is a good place to start. If you enter a refresh interval of less than 10 seconds, such as 1 or 2 seconds, you will probably notice the overhead, and you will probably be unhappy with this selection. If you are currently having performance problems, you may want to increase the default 10 seconds to a larger number, such as 30 seconds or so. Once you set the refresh interval, you can always change it by right-clicking on Replication Monitor in Enterprise Manager and selecting "Refresh Rate and Settings." [7.0, 2000] Updated 9-17-2004

61

***** If the subscriber data is being indexed heavily for the decision support needs of the organization, keep in mind that those same indexes can slow down how long it takes data from being moved from the distributor to the subscriber. The more indexes there are, the slower the replication process. This is because any new data moved to the subscriber must be indexed. In some cases, it might be beneficial to create an indexed view on the publisher, and then publish it as a table to subscribers. [2000] Added 10-9-2001 ***** The distribution agent, the log reader agent, the merge agent, and the snapshot agent all log their activity as they work. The amount of data they log depends on their verbosity setting. The more verbose the setting, the more overhead there is. The less verbose the setting, the less overhead there is. According to Microsoft, setting all of these settings to their lowest setting can boost replication performance from 10 to 15 percent. In most cases, there are two verbosity settings that need to be made: HistoryVerboseLevel and OutputVerboseLevel. These settings are made using the various agent utility programs, which are located in the Mssql7\Binn folder. Here are the commands used to turn the verbosity levels of each of these agents their least verbose setting: Distribution Agent distrib -HistoryVerboseLevel 1 distrib -OutputVerboseLevel 0 Log Reader Agent logread -HistoryVerboseLevel 1 logread -OutputVerboseLevel 0 Merge Agent replmerg -HistoryVerboseLevel 1 replmerg -OutputVerboseLevel 0 Snapshot Agent snapshot -HistoryVerboseLevel 1 snapshot -OutputVerboseLevel 0 The default value for the HistoryVerboseLevel is 2 (not 1), and the default value for the OutputVerboseLevel is 2 (not 0). Of course, if you are troubleshooting replication, you will not want to reduce these values. But if you are in production, and all is going well, you should consider changing the relevant default values in order to boost performance. [7.0, 2000] Updated 3-20-2006 ***** If you need replication agents to run frequently, say every minute or so, it is more efficient to set them to run continuously than it is from them to run frequently. This is because these agents require overhead to start and stop as they are used, which increases overhead. So if you have set the replication agents to run often, consider setting them to run continuously instead. On the other hand, if you only need the agents to run occasionally, once an hour or so, or longer, then this configuration is still more efficient than running them continuously. You may have to perform tests to see which option best meets your specific replication needs. [7.0, 2000] Updated 3-20-2006 ***** To optimize the performance of the distribution database, manually size it to what you believe will be the biggest size it will ever get. This can reduce overhead as SQL Server will not have to increase its size automatically as needed. In addition, be sure not to turn on the "Auto Shrink" and the "Auto Close" database options, as they will incur unnecessary overhead to the database. [7.0, 2000] Updated 3-20-2006 *****

62

If your SQL Server 2000 replication configuration will cause a large number of rows to be affected, consider using stored procedure replication. Significant overhead can be reduced if the execution of stored procedures is replicated instead of the data changes caused by the execution of one or more stored procedures. This is generally accomplished in snapshot or transactional replication when one or multiple stored procedures are specified as articles. [2000] Added 10-9-2001 ***** To help reduce overhead and the size of the distribution database, consider reducing the amount of time that log history and transaction retention is held. To do this, right-click on the "Replication" folder, then select "Configure Publishing, Subscribers, and Distributors." Next, click on the "Properties" button for the distribution database to make your change. [2000] Added 10-9-2001 ***** Avoid creating triggers on tables that contain subscribed data. They can significantly add to overhead and slow replication performance, including snapshot replication, transactional replication, and merge replication configurations. [7.0, 2000] Updated 3-202006 ***** To help you identify any potential replication performance issues, consider tracking these Performance Monitor counters:

Dist: Delivered Cmds/sec: Tracks the number of commands per second sent to subscribers from the distributor. Dist: Delivered Trans/sec: Tracks the number of transactions per second sent to subscribers from the distributor. Dist: Delivery Latency: The average amount of time it takes to for a transaction to be moved from the distributor to a subscriber.

The first two counters help you to get a feel for how busy your replication setup is. There are no absolute numbers to watch out for. Instead, you need to watch these counters over time to see if there is any significant change and if so, you need to investigate why, as this could indicate a potential performance issue. The Delivery Latency gives you a good feel for how much time it takes subscribers to get updated. Again, there is no ideal number for this counter. Instead, evaluate whether or not the latency you are seeing is livable. If it is not, then you will have to take steps to reduce latency to an acceptable figure. [6.5, 7.0, 2000] Updated 3-20-2006

63