SQL Server Magazine Forums

Spacer
< REFRESH >
Topic Title: SQL Server 2008 Replication Advice
Topic Summary: SQL Server 2008 Replication Advice
Created On: 09/22/2009 12:02 PM

View topic in raw text format.
 09/22/2009 12:02 PM
 User is offline  View Users Profile  Print this message

Author Icon
moflaherty

Posts: 3
Joined: 09/22/2009

Hi!

We have three installs of SQL Server 2008 Enterprise and would like to replicate them to a fourth SQL Server 2008 Enterprise server. 2 of the installs are remote (different city) and available via a 10 MB network connection. We would like to sync changes from those databases once a day. 1 of the installs is in the same building and it has access to a fiber connection. We would like to sync changes from this database say every 15 minutes.

The purpose of the 4th server is strictly for staging the three databases, writing a converter, and creating a completely new database schema with populated data. The new database will eventually be shipped to yet another server, so you can think of this specific server as a processing server only.

The databases are not very large nor transaction heavy; about 500 users across all 3 databases. However, they do need to remain semi-responsive 24/7, so we don't want to grind them to a halt with a replication process.

What is the best mechanism for replicating these databases? Is Log Shipping where we should be looking, or the traditional publish-subscribe functionality? Any advice would be greatly appeciated.

Thank you for your help!
Michael
    Reply     Quote     Top     Bottom    
 09/22/2009 04:39 PM
 User is offline  View Users Profile  Print this message

Author Icon
gunneyk

Posts: 1128
Joined: 07/27/2007

Michael,

How available do the 3 databases on the 4th server need to be? If you log ship you have to bump all the users out each time you restore the logs and of course it would be read only assuming you restored in Standby mode. The one you ship once a day is probably not a problem but if you want to do it every 15 minutes that is a lot of interrruption for anyone trying to view or read those copies. Transactional replication will make them available all the time. Bottom line is that you need to decide what kind of access you need on the copies and how old the data can be to determine the proper method.

-------------------------
Andrew J. Kelly
    Reply     Quote     Top     Bottom    
 09/24/2009 01:23 PM
 User is offline  View Users Profile  Print this message

Author Icon
moflaherty

Posts: 3
Joined: 09/22/2009

Hi!

There is no user access to the databases that are on the staging server; we will be authoring an SSIS package that will monitor for changes (change tracking) and convert changing into the new database (on the same server.) We would then replicate this out to another server when the time comes.

Thanks!
Michael
    Reply     Quote     Top     Bottom    
 09/24/2009 01:46 PM
 User is offline  View Users Profile  Print this message

Author Icon
gunneyk

Posts: 1128
Joined: 07/27/2007

It doesn't have to be a live user as any connection in the db needs to be killed before you can restore the next log. This sounds a little too complicated to get right on a forum post as there are lots of details that need to be considered to determien the correct strategy for your needs. I don't understand why you have a staging server in the first place. Why not use change tracking on each of the primary dbs and use SSIS to grab the data, convert it on the fly and update the target databases all in one shot?

-------------------------
Andrew J. Kelly
    Reply     Quote     Top     Bottom    
 09/25/2009 08:06 AM
 User is offline  View Users Profile  Print this message

Author Icon
moflaherty

Posts: 3
Joined: 09/22/2009

There is a fair amount of conversion and massaging of data that we felt it merited it's own server that is in isolation. The change tracking has some performance overhead as well (based on our testing.) [I know replication does too.] It seemed easier for us to bring the data from three locations into one server, especially because two of the sites are remote on a slow connection. (The plan is to dial up the update interval from once a day to something more often at the two locations and measure the performance.) We also felt that propogating the data into the server does create another potential backup location (though not the driving factor here.) I am ok considering running change tracking at three locations, though I was all excited about managing the code and processing from a single, detached location when I started.

We can run the SSIS conversion package on our staging server say every 15m; it does not have to be real time. So I would assume the connection issue could be managed. I was just curious if you or anyone out here had experience with log shipping vs. other Microsoft approaches for syncing remote databases; it sounds like we have a few options with SQL Server and I didn't want to waste the time testing every possible approach if there was a consensus on what works best. If our scenario is not typical, or I can't adequately define the problem out here, we can certainly try everything. Just trying to save some time.

Thanks!

    Reply     Quote     Top     Bottom    
 09/25/2009 08:48 AM
 User is offline  View Users Profile  Print this message

Author Icon
gunneyk

Posts: 1128
Joined: 07/27/2007

All of the mentioned approaches will work it is really a question of what suites your requirements more. You really need to write down (not here ) what all your requirements are for all aspects of the enviorment. Things such as how stale can the data be, what limitations do you have, how available all the parts need to be, how long canany given piece be off line and what will the impact be etc. etc. Then list the pros & cons of each of the approaches and see which fits your requirments best. Don't count SSIS out before hand just based on the amount of work to be done. That is what SSIS is designed for and I can assure you there are lots of companies doing extremely heavy massaging of data with SSIS every day. But at the same time there may be a slightly more simple approach that suites your needs as well. But the only way to know is to list every possible issue / requirement and go from there.

-------------------------
Andrew J. Kelly
    Reply     Quote     Top     Bottom    
View topic in raw text format.
< REFRESH >

FuseTalk Enterprise Edition - © 1999-2009 FuseTalk Inc. All rights reserved.