Merge replication problem

  • Merge Replication Scenario(Sql 2000)

    i have one central Server (publisher)-- 250 subscribers all over the world

    In beginning merge replication is setup from central to all subcribers for all 50 tables. dbsize is around 600 megabytes.

    Everything was working fine. but when we added 51st table to the publisher.when the snapshot runs to sync the new table to copy the schema and data. the snapshot is recreating schema and data for all the 51 tables not just the 51st table.

    this is causing the data about 600 megs to be retransmitted to all the subscribers on addition of new table.

    How can we restrict the snapshot from recreating the whole db instead of just the newly created table .

    Any Suggestions.

    Edited by - nazim on 07/24/2003 12:48:47 AM

  • I don't think it's possible to make a snapshot of just the new table unless you create a separate publication.

    What I usually do is copy the new table manually to all subscribers and when run a new snapshot with reinitalizing (Subscribers already have schema and data). But I can imagine that that's quite difficult in your case with 250 subscribers.

    [font="Verdana"]Markus Bohse[/font]

  • hi!

    quote:


    How can we restrict the snapshot from recreating the whole db instead of just the newly created table .


    to my knowledge it is not possible to conduct schema changes to replicated objects without invalidating the snapshot. it's more or less an organizational problem when rolling out such changes to make sure every client is able to ge the new snapshot applied when connected to a network providing reasonable speed ...

    best regards,

    chris.

  • Try creating multiple publications. We segregated our replication (transactional not merge, but that shouldn't make any difference) into multiple publications to make our snapshots easier to manage.

    Our largest tables each have their own publication.

    You may want to start a second publication, and when that gets too unwieldly, create a third, etc.

    Bill Bertovich

    bbertovich@interchangeusa.com


    Bill Bertovich
    bbertovich@interchangeusa.com

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

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