Home > Articles > Databases > SQL Server

Setting Up Transactional Replication with SQL Server

  • PrintPrint
  • Share ThisShare This
  • DiscussDiscuss
Setup isn't the only piece of the replication puzzle; yet, getting it wrong can cause many headaches. In this second episode of his replication series, Baya Pavliashvili teaches you how to set up replication through wizards and through scripts.

In my first article in this series, I mentioned that setup is only one of the many steps involved in managing replication. If you have done your homework and planned for replication appropriately, setup is relatively straightforward. Yet, it is very important to get things right the first time. Mistakes made during replication setup are not easy to correct and might require downtime.

Much of replication setup can be accomplished through wizards. However, it is often easier to set up replication by executing replication stored procedures. Indeed, if you have development and quality assurance servers that should be identical to your production environment, you might not want to click through the wizard screens each time you configure replication.

This article covers setting up transactional replication by using wizards as well as by running replication stored procedures. Hope you find it useful.

NOTE

This article uses replication terminology explained in the previous article. Please be sure to become familiar with all terms prior to reading further.

The Scenario

To make the examples shown in this article a bit more realistic, let's consider a sample problem in which transactional replication could be helpful. Suppose that you are a database administrator managing a server queried by hundreds of concurrent users each day. When you first joined the company, the user base was small, and a single server was sufficient for transaction processing as well as reporting. But imagine that your PUBS database has grown by leaps and bounds, and users who run reports are complaining about the application being very slow. You also notice that the other set of users, who enter data eight hours a day, complain about application screens—often "hanging." You have examined your database design and queries and have done all the tuning you can. Yet data entry and reporting users still hate each other... and you. After consulting your boss, you find that she is willing to buy another server (or two) if that will help, but you better have this problem fixed soon. Congratulations! It's time to learn transactional replication.

  • Share ThisShare This
  • Save To Your Account

Discussions

comments powered by Disqus

Related Resources

There are currently no related podcasts. Please check back later.

Careful with those NULLs
By on October 13, 2010Comments

Many folks (including me) use NULL values in their databases. There's actually a bit of controversy on even having them - but I don't fall on the side of never using the. But you do need to exercise some care...

The true value of conferences
By on October 5, 2010Comments

I recently returned from the "SQLBits" conference in York, England. I met a lot of folks that I've seen before at other conferences, but I also met a fair amount that had not been to a SQL Server conference before.

Finding Big Data
By on September 16, 2010Comments

I get asked from time to time about locating "Big Data" - or large sets of data for an application.

See All Related Blogs