SQL Server Replication and Backup

  • The Company I am working for has tow locations 250 Km Apart

    (One Central (H.Q.) And One Remote)

    The Sites are connected with a 512KBPs F.R Comunication

    We are considering to Unite Databases By Using SQL Server Replication Since Most Of the Work is Select Queries and Small Percent Is Update , at least at the Remote Site.

    In the Central Site (H.Q) there are many Systems working and Updating masivly the Databses

    So The replication will be only to Nessasery Tables to the remote site to reduce trafic

    (Application considerations are already have been Taken In To Account)

    I wonder what kind of Infflunce does the replication has on backups and restores.

    Can I restore the Publisher Database and still be sincronized (Merge Replication is what I have In Mind)

    Do I need To change my Backup strategy from simple to more complex like Backing the Databse Up To the minute ?

  • This was removed by the editor as SPAM

  • quote:


    The Company I am working for has tow locations 250 Km Apart

    (One Central (H.Q.) And One Remote)

    The Sites are connected with a 512KBPs F.R Comunication

    We are considering to Unite Databases By Using SQL Server Replication Since Most Of the Work is Select Queries and Small Percent Is Update , at least at the Remote Site.

    In the Central Site (H.Q) there are many Systems working and Updating masivly the Databses

    So The replication will be only to Nessasery Tables to the remote site to reduce trafic

    (Application considerations are already have been Taken In To Account)

    I wonder what kind of Infflunce does the replication has on backups and restores.

    Can I restore the Publisher Database and still be sincronized (Merge Replication is what I have In Mind)


    You should be able to restore the publisher in this fashion.

    quote:


    Do I need To change my Backup strategy from simple to more complex like Backing the Databse Up To the minute ?


    I would probably go with a Full recovery model. In fact I might also go one step further and say that you should create a subscriber to do the updating work in your central office that then syncs the changes back to your publisher. Then the remote subscriber can sync to the publisher to get those changes. In this way your publisher can have better performance while the data is being modified at the subscriber. Also, if something were to happen to the publisher database you can then easily promote your "local" subscriber to be your publisher.

    On my system I have a publisher and several subscribers. All the data manipulation is done on the subscribers database. Once the data is deemed worthy it is then merged to the publisher so that the other subscribers can get to it. The subscribers always change data using marked transactions and get restored to those marked transactions on a daily (sometimes hourly) basis. In this way if there is a problem with the updating of data we simply restore the subscriber database. Our publisher almost never has the data modified on it directly. In fact I'm the only one who has rights to do that as I'm the DBA.

    Gary Johnson

    Microsoft Natural Language Group

    DBA, Sr. DB Engineer




    Gary Johnson
    Microsoft Natural Language Group
    DBA, Sr. DB Engineer

    This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed in this post are my own and may not reflect that of my employer.

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply