In the Microsoft replication model, SQL servers have three roles: publisher, subscriber, and distributor. These roles can be mixed and matched to suit your organization and budget. Companies wishing to take advantage of replication should be aware of all these roles and the scalability of each server performing each task.
http://www.itknowledge.com/reference/standard/1576101495/ch04/106-110.html (2 of 4) [1/27/2000 6:15:49 PM]
Publisher Server
The publisher is the server where the source data is stored. When designing a system, many organizations begin with this server before moving on to the distribution or subscription of the data. This server is typically the production machine with the mission-critical data on it, as well as the load of performing production tasks.
Adding the publication tasks to a production server can usually be done without affecting performance. However, setting too tight a schedule for the replication process can place a burden on your production server. When deciding whether your publishing server should be your distribution server, look very closely at the existing load on your server to ensure that you won’t overload your production machine. I recommend using the distributed server environment for replication whenever possible.
Data restrictions in the form of constraints or triggers should be placed on the publishing server since all changes should be applied here first, then replicated to the subscribing servers. This method allows for the centralized
administration of the data that will be replicated. Subscribers should not be allowed to edit replicated data at their locations; edits should be applied to the publishing server so that the data remains consistent across the servers.
Subscriber Server
The subscriber is the server that receives data to be published for query and report purposes. The intent of the subscriber server is to provide a local, fast data source to run queries against. Microsoft documentation states that the subscriber server should not modify the data it receives through the replication process; the replication process requires both data sets to be synchronized in order to function properly.
It is very important to treat the data on subscriber servers as read-only. This is not to say that you should set the properties of the database to read-only; doing so would preclude any changes being written to the database by the publisher.
Instead, you should make all your changes at the source of the data and allow the changes to be replicated to the subscribers. This will keep all the tables synchronized and up to date.
Updates to the data on a subscriber are received as either SQL commands that must be executed or as stored procedures. Using stored procedures can
increase replication performance. However, do not try to implement replication through stored procedures to begin with—work up to it slowly.
Take time to understand the process before you complicate matters. In addition, constraints and triggers placed on your data are enforced on the publication server and should be not be added to the subscriber server.
Previous Table of Contents Next
http://www.itknowledge.com/reference/standard/1576101495/ch04/106-110.html (3 of 4) [1/27/2000 6:15:49 PM]
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.
http://www.itknowledge.com/reference/standard/1576101495/ch04/106-110.html (4 of 4) [1/27/2000 6:15:49 PM]
Brief Full Advanced Search
Search Tips
To access the contents, click the chapter and section titles.
Microsoft SQL Server Black Book
(Publisher: The Coriolis Group) Author(s): Patrick Dalton ISBN: 1576101495 Publication Date: 07/01/97
Search this book:
Previous Table of Contents Next
Distribution Server
The distribution server is the traffic cop of the replication process. The purpose of the distribution server is to make sure all servers receive the publications they have subscribed to in a complete and error-free state. The distribution server will continue to function if one or all of the subscribers happens to go offline. This fault tolerance is what sets Microsoft SQL Server replication apart from the two-phased commit.
Distribution processes and the concept of implementing a distribution server are directly in line with the Microsoft distributed server concept. As the load for any process becomes too much for a server to handle, simply increase the amount of disk, memory, or processor power you have on that server.
Replication benefits from this concept by placing the distribution tasks on a dedicated server that can keep track of the publishers and subscribers and whether they are up to date.
Another huge benefit of using the distribution server is the fault-tolerance it provides your distributed data scheme. If a WAN/LAN connection goes down, the distribution server maintains a list of the information that must be passed to the subscriber when it becomes available again.
Scenarios
In this section, I’ll focus on five scenarios: Central Publisher, Central Publisher With Remote Distribution, Publishing Subscriber, Central
Subscriber, and Multiple Publishers Of A Single Table. You can borrow from one or a few of these scenarios and mix and match the features you require for
http://www.itknowledge.com/reference/standard/1576101495/ch04/110-112.html (1 of 3) [1/27/2000 6:15:50 PM]
Go!
Keyword
---Go!
your organization. Because your servers can perform many roles, you have great flexibility.
Considerations
Before we begin with the actual scenarios, let’s run through the major items you should consider when setting up servers for replication.
Planning
Plan your replication on paper before trying to implement any portion of the process. Failing to plan your model can cause you many headaches. If you can’t get the process to work on paper, you won’t get it to work on Microsoft SQL Server.