SQL Server Replication

SQL Server replication allows database administrators to distribute data across multiple 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. Replication supports manipulating 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.

Any replication scenario has two main components:

• Publishers have data to offer to other servers. A 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.

Read More

Microsoft SQL Server: Snapshot Replication

By Mike Chapple

There’s nothing preventing a single system from acting in both of these capacities. In fact, this is often the design of large-scale distributed database systems.

SQL Server Support for Replication

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 in which 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, the agent uses a predefined conflict resolution algorithm to determine the appropriate data. Merge replication is commonly used by laptop users and others who cannot be continually connected to the publisher.

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

If you're working with SQL Server 2016, choose your edition based upon your replication needs. Each edition has differing capabilities when it comes to replication support:

• Subscriber support only: Express, Express with Tools or Advanced Services and the Web editions offer limited replication capabilities, capable of acting as a replication client only.
• Full Publisher and Subscriber support: Standard and Enterprise offer full support, with Enterprise also including Oracle publishing, peer to peer transactional replication, and transactional replication as an updateable subscription.

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.