286 Chapter 8

Implementing Availability and Replication

will now become the principal. After the former principal database
comes online again, executing a manual failover will resync the
databases and swap the roles back.

Implement Replication
Replication is one of the oldest data distribution techniques supported
by SQL Server. The purpose of replication is to copy data or transac-
tions from one server to another. While this can be a very effective dis-
tribution technique, there is no support for failover or transparent client
redirection, so it is a marginal availability solution in most cases. Repli-
cation can still be an excellent data distribution technique, however.

Understand Types of Replication

SQL Server 2008 supports three major varieties of replication:
Snapshot replication This approach focuses on copying data from
one database to another. Entire data pages are copied from the pub-
lisher to the subscriber, meaning that the data is aging from the time
of the initial copy to that of each subsequent copy. While you can
configure the frequency of replication, this approach works best when
you have small volumes of data that are either nonvolatile or tolerate
data latency.
Transactional replication This is the standard replication model. In
this approach, the publishing server stores transactions in its transac-
tion log for replication. Periodically, a log reader service gathers the
transactions and sends them to a distribution server that then executes
the transactions on each of the subscribing databases. This process
can be scheduled to occur at regular intervals or can be configured to
execute whenever transactions commit on the publishing server.
Merge replication This model values data independence over
consistency. Unlike snapshot and transactional models that require
the subscribing databases to be treated as read-only, the merge rep-
lication model permits changes to the subscribing servers with the
ability to merge the changes made in the subscriber with the data
on the publishing server. Although this increases the independence
of the servers in the replication model, it also increases the prob-
ability of data synchronization problems between the publisher and
subscriber databases.
 Implement Replication 287

There are variations on each of these techniques, including the use

of a two-phase commit on the subscriber and numerous topologies such
as the central publisher or central subscriber. All three of these models use
the database servers participating in the model in slightly different ways:
Publisher In most replication scenarios, the publisher is the pro-
duction server that accepts all transaction activity and makes that
activity available for replication to other servers. The publisher will
generally store transactions to be replicated in its transaction log
until the distributor picks them up for delivery.
Distributor This is the service that is responsible for delivery of
replicated data. In a typical mode, the distributor will retrieve data
from the log of the publisher and store that data in its own log until
it can distribute the data to the subscriber. It is essentially a store-
and-forward service.
Subscriber The subscriber receives the replicated data from the
distributor. In most cases this database must be treated as read-only
since the transaction activity should occur on the publisher. There
are exceptions to this rule, however, including merge replication
models and updating subscribers.

Additionally there are some replication-specific terms with which you

Data Administration
should be familiar. We will assume that these terms are understood for
the remainder of this chapter:
Push subscription A subscription model in which the distributor
services push data to the subscriber. SQL Agent jobs running on the
distributor will periodically connect to the subscriber and execute
transactions necessary to bring the subscriber current.
PART III
Pull subscription With a pull subscription model, the subscriber
services retrieve transactions from the distributor for execution to
keep the subscriber current. Pull subscriptions allow some of the
overhead of replication to move from the distributor to the sub-
scriber, which may load-balance the model better.
Article An individual collection of replicated data usually associ-
ated with a table. Creating an article from a table allows the adminis-
trator to filter out columns or rows that they wish to exclude from the
replication scenario.
Publication A collection of articles usually associated with a data-
base. A subscriber can subscribe to either an individual article or
the entire publication.
288 Chapter 8
Implementing Availability and Replication

In addition to these server roles and the replication types previously dis-
cussed, it is also possible to combine these components in different ways to
create various replication topologies. A topology is a collection of replica-
tion services that are combined in a specific way to accomplish a desired
goal. Some of the more prominent topology patterns are listed here:
Central subscriber It is possible to have multiple publishers replicate
data to a single subscriber. The data for each publisher article may
even be published to the same table in the subscriber as long as each
publisher’s data is distinct. This pattern, illustrated in Figure 8.18, is
most common where there is a centralized data need for reporting or
decision making.

Figure 8.18 : Central subscriber

Publisher A
Subscriber
Table
Publisher B

Publisher C

Central publisher You can also configure a single publisher that can
partition data to various subscribers. Assuming that each subscriber
needs only a subset of the data, the administrator can create multiple
articles, each one filtering out data for a particular subscriber. Each
subscriber can then receive the data that’s relevant for them. This
approach, pictured in Figure 8.19, is useful when data is centrally col-
lected but must be distributed locally for decentralized processing.

Figure 8.19 : Central publisher

Subscriber A
Publisher Article
Table A
Subscriber B Article
B

Subscriber C
Article
C
 Implement Replication 289

Regional publishers/subscribers It is also possible that each

server may need to maintain its own distinct data but also send
and receive replicated data from other servers. This approach,
pictured in Figure 8.20, supports a highly decentralized environ-
ment. One of the problems with this model, however, is its ability
to scale. Adding additional nodes to the model will exponentially
increase the overhead for each added node.

Figure 8.20 : Regional publishers/subscribers

Publisher/ Publisher/
Subscriber A Subscriber B
Publish
Article A

Publish
Article B

Distributed subscriber/republisher Designers often use this

model when data must replicate to more than one subscriber but
those subscribers are geographically located where it is either
expensive or impractical to perform a direct replication. All data

Data Administration
will replicate to a single subscriber that has more convenient
access to the ultimate subscribers. The subscriber then republishes
the data to the subscribers that need it. In this model, pictured in
Figure 8.21, the central server is responsible for both subscription
and publication services.

PART III
Figure 8.21: Distributed subscriber/republisher

Subscriber A

Publisher Pub/Sub
Table Table

Subscriber C

Subscriber C
290 Chapter 8
Implementing Availability and Replication

Of course, there are other patterns that you can use, and almost
limitless combinations of these patterns, so be creative. Just be sure to
do production-level performance and reliability testing on your models
before taking them live. What looks good on paper will not always work
so well in the real world.

NOTE Before you can configure replication, you must install it

into the servers that will participate in your replication topology.
If you have not already installed replication on all participating
servers, go back to the SQL Server Installation Center and add the
replication feature to your servers. It will also make the process of
configuring replication easier if you connect your Object Explorer
in SSMS to all the Data Engine services that will participate in
your replication model.

Configure the Replication Distributor

In this example, the PrimaryServer instance will act as publisher, the
SecondaryServer instance will act as subscriber, and the MasteringSQL
default instance will act as the distributor. Remember that it is possible
for a single server to play any combination of roles.
1. Start the replication process by connecting to the distribution server.
2. Right-click the Replication node in the Object Explorer for the
target distribution server and select Configure Distribution from
the menu. (This replication node will not be present if you have
not installed replication.)
3. Advance past the first page of the wizard and you will see a page
that asks you to either configure the selected server as a distributor
or point this server’s publications to another distributor. Since this
server will act only as a distributor, you will select the first option,
as pictured in Figure 8.22. Click Next.
4. In the next page of the wizard, configure the location of the snap-
shot folder. Whenever the distributor needs to perform a synchroni-
zation between the publisher and subscriber, it will use an article
snapshot. In cases where the subscriber will use its own distribution
agents (i.e., pull subscriptions), those agents will need access to this
folder. You will need to use a network location such as a UNC name
before you will be able to support pull subscriptions. The SQL
 Implement Replication 291

Agent service account on the subscriber will also need permissions

to access this share. In Figure 8.23, this dialog shows the user of a
share called ReplSnap. Click Next to continue.

Figure 8.2 2 : Setting the distributor

Figure 8.2 3 : The distribution snapshot folder

Data Administration

PART III

5. The screen that now appears will provide the configuration of this
database, specifically the database name and file locations. The
default name is distribution, which we will retain for this example
292 Chapter 8
Implementing Availability and Replication

as pictured in Figure 8.24. Note that when you configure distribu-

tion, you are creating a database that the distribution agents will
use for storing and forward transaction activity. The log is heavily
used in this database and should be physically positioned accord-
ingly. Click Next to advance.

Figure 8.24 : The distribution database

6. The distribution server must authorize publishers before they will

be able to use its distribution services. This next page authorizes
publishers to use this distributor. By default, the distribution server
can always publish to itself. You must add any other publishers here
before they can use this distributor. Click the Add button at the
bottom of the dialog to add a publisher. You will see that you can
add either a SQL Server or an Oracle publisher. Select SQL Server
and connect to the server that you plan to use as the publisher.
7. You should see a configure dialog like that shown in Figure 8.25.
Click Next to continue.
8. Enter a strong password and click Next. (This simple dialog is
not pictured here.) Publishing servers may occasionally need to
connect to the distributor to perform administrative tasks on the
distributor configuration. To do this, they will have to provide a
distribution password. This is not the password of any existing
account but rather an administrative password that the publisher
must give to be allowed to access distribution configuration.
 Implement Replication 293

Figure 8.25 : Configuring publishers

9. The final page in the wizard allows you to immediately configure

the distributor or generate a script that you can execute later or on
a different server. (You can also do both if you wish.) Select the
option to configure the distributor now and click Next, which
navigates to the summary page.

Data Administration
10. Review the page for accuracy and click Finish when you’re ready
to execute the configuration. When the replication is complete,
click Close.

Configure the Replication Publisher

PART III
Now that you have successfully configured the distributor, it is time to
create publications. We will publish articles from the pubs database on
the PrimaryServer instance. If you have not set the recovery model of
this database to Full or Bulk-Logged, you must do that now before you
can configure publishing. Then follow these steps:
1. To begin, expand the Replication node of the server from which you
wish to publish. Right-click the Local Publications node and select
New Publication. This will start the New Publication Wizard. Click
Next to advance past the first page.
2. The next page allows you to set the distributor. This dialog is like
the one previously illustrated in Figure 8.22. If this publisher will
294 Chapter 8
Implementing Availability and Replication

act as its own distributor, you can configure the distributor now.
In this example, however, you will point to the distributor that
we configured in the previous step. Click the second option in the
dialog to enable the Add button.
3. Click the Add button and connect to the server previously config-
ured as the distributor. Then click Next to advance.
4. Provide the distributor password that you specified when you
configured the distributor. (You will not be able to make an adminis-
trative link to the distributor without this resource password.) After
providing the password click Next to advance. (This simple page
contains only the password prompt and is not pictured here.)
5. Select the database that you wish to publish from the list of
databases that are eligible for publication. In this case, only the
pubs database is on the list. Data from multiple databases will be
published as multiple publications. Click Next to continue.
6. You will now see the page illustrated in Figure 8.26, which lists all
publication types previously discussed. Refer to the introductory
section of this chapter if you need a refresher on replication types.

Figure 8.26 : Selecting a replication model

You will see one additional option; that is Transactional publication

with updatable subscribers. This option allows data modifications at
the subscriber by using a two-phase commit to commit the subscriber
change immediately to the publisher to ensure data integrity. Use this
 Implement Replication 295

option with caution because it can often result in significant perfor-

mance degradation.
7. Select the Transactional Publication option and click Next to
advance. In this example, we will use a standard transactional
replication. There are advantages and disadvantages to each
approach, but the transactional method was the first replication
model supported and it is still the most common approach due to
its lower resource consumption and greater flexibility.

NOTE We wish that we had the time and space to cover all of
the replication models more exhaustively, but that is unfortu-
nately not possible. The good news, though, is that this informa-
tion should be enough to get you going and the replication
process is very well documented in the SQL Server Books Online
when you are ready to dive deeper. Again, don’t be afraid to
experiment with the options and be sure to do some testing
before you pull the trigger in production.

Now it is finally time to decide what you are going to publish. You
can publish tables, views, and stored procedures as articles. If you
publish a table, it must have a primary key.

Data Administration
8. On the right side of the dialog pictured in Figure 8.27, you will see
a button with two options, one to set properties for the selected
article and one for all articles. Review these properties carefully
on your own. You will control much of the replication behavior
here, including copying related artifacts, doing type conversions,
and other useful options. In our example, we will replicate only a
limited number of columns in the authors table. Select the check PART III

boxes for the authors table as shown and click Next to advance.
9. The next step is to select articles to filter. The previous dialog
allowed you to filter out any columns that you did not need. The
next dialog provides the ability to do row filtering based on criteria
that you provide. Figure 8.28 illustrates a completed dialog. To add
filtering for an article, click the Add button on the right, which will
be enabled if there are any articles remaining that do not have
filters. This will open the dialog pictured in Figure 8.29, where you
will provide a 7(%2% clause for the filter statement to indicate which
data you want to include in the article. In our example, we are only
publishing authors that live in the state of California. Click Next on
the dialog to advance.
296 Chapter 8
Implementing Availability and Replication

Figure 8.27: Selecting articles for publication

Figure 8.28 : Selecting articles to filter

10. The initial synchronization of the articles requires a snapshot

distribution to the subscriber. If you would like to generate the
initial snapshot immediately upon a new subscriber coming
online, select the check box on the next dialog. (This dialog has
only these two options and is not pictured.) Otherwise, the
snapshot will be generated on a schedule and the subscription
will not be available until after the snapshot generates and syncs
with the subscriber.
 Implement Replication 297

Figure 8.29 : Configuring an article filter

11. Select immediate generation of the snapshot and click Next.

12. The following dialog will request security account information
for two agents, the snapshot agent and the log reader agent. The
snapshot agent is responsible for doing snapshot syncs and must
execute under an account that has permissions to execute the

Data Administration
snapshot on the subscriber. The log reader agent is responsible for
retrieving transactions from the publishing log. You should use
domain accounts with necessary permissions for these agents.
This is pictured in Figure 8.30. Click Next to advance.

Figure 8.30 : Configuring agent security

PART III
298 Chapter 8
Implementing Availability and Replication

13. Decide if you want to commit the configuration at this time or

generate a script to commit the configuration at a later time or place.
(This is similar to the distribution configuration.) Click Next and
advance to the summary screen.
14. Don’t forget to enter the name of the publication at the top of the
summary screen. It’s easy to miss but the Finish button will not
enable without it. We will call our publication pubs. Click Finish
when you are ready to commit your configuration.
15. After the wizard reports successful creation of your publication, go
back to the Object Explorer. You should now see the pubs publica-
tion in the Local Publications folder in the PrimaryServer instance.

Configure the Replication Subscriber

The last step is to configure the subscriber. We will use the Secondary-
Server instance as the subscriber in our example:
1. Connect to that server in the Object Explorer and locate the Local
Subscriptions folder.
2. Right-click the folder and select New Subscriptions from the
menu. Click Next to advance past the first page of the wizard.
3. Point to the publisher. Open the publisher drop-down list at the
top of the dialog and choose the option to connect to a SQL Server
publisher.
4. Connect to the server that you configured as the publisher. This
will list the available publications in the dialog, as illustrated in
Figure 8.31. Select the pubs publication and click Next to continue.
5. Choose either a push or a pull subscription and click Next. (This
page has only these two options and is not illustrated.) Remember
that push subscriptions run the agents on the distributor and pull
subscriptions use the resources of the subscriber. You must have
configured the distributor to handle pull subscriptions by using a
network path for the snapshot folder before this option will
execute without error. Select a pull subscription for this example
and click Next.
6. The next page, pictured in Figure 8.32, has two functions. First, it
allows you to specify the target database for each subscription. If
you click in the cell for the subscription database, you can either
 Implement Replication 299

select a database from a list or create a new database. If you have

not already created the database that will host the subscriptions,
this is your opportunity to do so. Second, this dialog also allows
you to add subscriptions through the Add Subscriber button at
the bottom of the page. This example shows a database named
PubsSub. Click Next to continue.

Figure 8.31: Selecting a publication

Data Administration
Figure 8.32 : Selecting subscribers and databases

PART III
300 Chapter 8
Implementing Availability and Replication

7. Similar to configuring publishing, the next dialog allows you to

specify how the agents will authenticate to the servers upon which
they will run. Click the ellipsis on each subscriber row to open the
security configuration. These dialogs are similar to those previ-
ously shown and are not illustrated here. Click Next to advance.
8. The next dialog provides configuration for the synchronization
schedule. You have three options:
ß Run continuously, which will run the agents whenever there
is work to do. This will provide the best concurrency, but at a
higher resource cost.
ß Run on demand, which will delay execution until manually
triggered.
ß Run on a schedule. If you select the option to set a schedule, you
will see a standard SQL Agent scheduling screen where you will
be able to configure the schedule.

Figure 8.33 shows these options. Select Run Continuously for this
example. Click Next to continue.

Figure 8.3 3 : Setting the synchronization properties

9. The next dialog is similar except that it allows you to specify how
the subscription will be initialized, either immediately or on the
first sync task. If you choose to wait for the first sync task, you will
 Implement Replication 301

not see any data in the article until a database modification occurs
on the publisher and that transaction replicates to the subscriber.
Choose to initialize immediately. This is a simple dialog and is not
pictured here.
10. You are almost done. Click Next and choose the option to create
the subscription immediately or generate a script.
11. Click next to review the summary page, and then click Finish to
complete the wizard.

Once the wizard reports that you have successfully created the sub-
scription, you can go back to the Object Explorer. You will now see a
table in the target database with the same name as the article that you
created, in this case authors. Since we configured this to initialize imme-
diately, you should be able to select from the table and see the initial
snapshot of data.
Additionally, if you make a modification to the published data on
the publishing server, you will be able to select from the subscription
table and see the change. Do a couple of experiments with your data-
bases and see how long it takes for the subscriptions to update.

Data Administration

PART III