April 2, 2009 at 1:49 pm
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.
April 6, 2009 at 12:19 pm
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.
September 11, 2013 at 2:56 pm
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.
[font="Times New Roman"]Anil Kubireddi[/font]
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply