Need to Reinitialize Transactional replication on Large database

  • I am wondering if anyone has any suggestions regarding the reinitialization of replication on a database that is over 100 GB.

     

    We can not afford (time wise) to reinitialize this through the gui.   Does anyone have any ideas on what to do, or where a good white paper on the subject may be?

     

    Thanks..............Jeff

     

     


    "Keep Your Stick On the Ice" ..Red Green

  • There's a good replication section in the forums of http://www.sqlmag.com.

     

    Try that and also google it.

  • Jeff,

    Do you know how many tables involved the replcation in this 100GB database and which tables are out of sync?

     

  • Allen...I went on vacation and came back to a subscription that is flagged for reinitialization.  This was over a week ago so am assuming that all of the tables need a little help..

    ...Jeff


    "Keep Your Stick On the Ice" ..Red Green

  • Allen...

    You had me thinking on the way home last night.   There are 106 articles in the transactional push subscription.  Only 4 of these articles (tables) are of any size worth mentioning.

     

    Do you have some idea about transfering a couple of large tables only.

     

    Here is what I am thinking...

    • Drop publication and subscription
    • recreate publication with my scripts
    • Add articles (except for the 4 large ones)
    • rebuild the subscription with my scripts
    • run the initial snapshot
    • Check with Allen and see if he has a nifty way to move a large table or two or three or four

     

    Any suggestions?


    "Keep Your Stick On the Ice" ..Red Green

  • Off the top of my head, I'm pretty sure you can create a snapshot of a subscription, and manually copy it to the subscriber.

    If the subscriber is on a slow lan, or a distance away from your distributor, copy the snapshot to a removable HDD, and take the drive to the subscriber.

    I use multiple publications for large databases one for static tables, one for frequently updated tables, and another for large tables. This way each subscription can be restarted as needed interferring with the others.


    Julian Kuiters
    juliankuiters.id.au

Viewing 6 posts - 1 through 5 (of 5 total)

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