SQL Server replication allows database administrators to distribute data to various servers throughout an organization. You may wish to implement replication in your organization for a number of reasons, such as:

• Load balancing. Replication allows you to disseminate your data to a number of servers and then distribute the query load among those servers.


• Offline processing. You may wish to manipulate data from your database on a machine that is not always connected to the network.


• Redundancy. Replication allows you to build a fail-over database server that's ready to pick up the processing load at a moment's notice.

In any replication scenario, there are two main components:

• Publishers have data to offer to other servers. Any given replication scheme may have one or more publishers.


• Subscribers are database servers that wish to receive updates from the Publisher when data is modified.

There's nothing preventing a single system from acting in both of these capacities. In fact, this is often done in large-scale distributed database systems. Microsoft SQL Server supports three types of database replication. This article provides a brief introduction to each of these models, while future articles will explore them in further detail. They are:

• Snapshot replication acts in the manner its name implies. The publisher simply takes a snapshot of the entire replicated database and shares it with the subscribers. Of course, this is a very time and resource-intensive process. For this reason, most administrators don't use snapshot replication on a recurring basis for databases that change frequently. There are two scenarios where snapshot replication is commonly used. First, it is used for databases that rarely change. Second, it is used to set a baseline to establish replication between systems while future updates are propagated using transactional or merge replication.


• Transactional replication offers a more flexible solution for databases that change on a regular basis. With transactional replication, the replication agent monitors the publisher for changes to the database and transmits those changes to the subscribers. This transmission can take place immediately or on a periodic basis.


• Merge replication allows the publisher and subscriber to independently make changes to the database. Both entities can work without an active network connection. When they are reconnected, the merge replication agent checks for changes on both sets of data and modifies each database accordingly. If changes conflict with each other, it uses a predefined conflict resolution algorithm to determine the appropriate data. Merge replication is commonly used by laptop users and others who can not be constantly connected to the publisher.

Each one of these replication techniques serves a useful purpose and is well-suited to particular database scenarios.

If you're working with SQL Server 2005, you'll need to choose your edition based upon your replication needs. Each edition has differing capabilities:

• Express Edition has extremely limited replication capabilities. It's able to act as a replication client only.
• Workgroup Edition adds limited publishing capabilities. It's able to serve five clients using transactional replication and up to 25 clients usin merge replication. It can also act as a replication client.
• Standard Edition has full, unlimited replication capabilities with other SQL Server databases.
• Enterprise Edition adds a powerful tool for those operating in mixed databa

  SQL Server Replication

  se environments -- it's capable of replication with Oracle databases

As you've undoubtedly recognized by this point, SQL Server's replication capabilities offer database administrators a powerful tool for managing and scaling databases in an enterprise environment.