Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Schema Change on Table with Transactional Replication Expand / Collapse
Author
Message
Posted Thursday, April 2, 2009 1:49 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, August 18, 2014 4:09 PM
Points: 120, Visits: 211
SQL Server 2005 SP3
We have multiple databases whose data is replicated to one "main" database. This uses transactional replication (we are not using updatable subscriptions).
Some of the transactionally replicated tables have new columns added to them. (Not all of the replicated tables have been altered, only some.)

There are three publishers and each one has one subscriber--which all target the same database.
Example:
Publisher Subscriber
DatabaseA DatabaseM
DatabaseB DatabaseM
DatabaseC DatabaseM

This is done to allow all of the data to be rolled up to one location and queried.

If I allow replication to replicate DDL changes, then when the first publisher updates the subscriber with the new tables. Fair enough.
However, the other two publishers also have to be updated. When I apply the schema changes to the other two publishers, the distributor agent fails stating column names must be unique (error 2705). The error makes sense as the distributor is trying to apply the DDL changes to the subscriber which already occurred when the first publisher was updated.

I also tried dropping the article from the subscription and publication. This allow me to update the schema at the publishers and the subscriber with no problems. However, when I add the tables back to the publication, replication wants to re-replicate the data from the publishers to the subscriber. The distributor now reports the error 2627 (violation of PK constraint). It is attempting to replicate the data which already exists at the subscriber.

Is there anyway to "tell" the distributor to just assume all of the data is there and only begin replicating new data?

I tried to use different agent profiles to ignore the errors (2705 for the first 'method' and 2627 for the second method) but this does not fully address the issue.
I do not want to delete the data at the subscriber because I do not want to have to re-replicate 60 million records over the WAN.

I would really like to just tell replication to assume the published articles' data already exists at the subscriber and replicate changes beginning now.

I appreciate your assitance.
Post #689319
Posted Monday, April 6, 2009 12:19 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, August 18, 2014 4:09 PM
Points: 120, Visits: 211
In case anyone is wondering, I was able to find a solution for this.
Drop the subscription(s)
Update the schema
Re-create the subscription setting the property @sync_type to 'replication support only'

See the SQL Server BOL information for the sp_addsubscription usage for this property and information when using this value.
Post #691328
Posted Wednesday, September 11, 2013 2:56 PM


Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Thursday, April 10, 2014 9:41 AM
Points: 695, Visits: 264
Instead of dropping and adding subscriptions, we may also alter the SP_MSins_<ArticleName> sp, in the subscribers by adding a condition at the start of SP, to check if the record exists, return esle proceed. This way it works for managing DML changes, i am wondering if there is any sp like that to manage DDL changes.

Anil Kubireddi
Post #1493909
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse