SQL Server transactional replication republication

Question

We have a transactional replication setup where the subscriber is also a publisher to a second set of subscribers. I think this is because of the slow link between the primary publisher and the subscriber. The subscriber publishes the same set of articles to multiple local subscribers.

One problem we have is when the primary publisher/subscriber setup needs to be reinitialized, we have to remove the second publisher/subscriber setup. We get errors regarding dropping of tables otherwise. They can't be dropped by the initialization process because they are being used for replication by the second setup.

Maybe this is the way it has to be done but I'm wondering if there is a better way. Looking for any tips or suggestions.

Thanks, Kevin

Answer 1

Maybe. The procedure to add an article ( sp_addarticle ) takes a parameter @pre_creation_cmd that specifies what to do before creating the article. The default is "drop", but can be "none" (do nothing), "delete" (deletes all data in the destination table), or "truncate" (truncates the destination table). In your case, I'd choose "delete" since you can't truncate a replicated table, either.

But I have to say that if it were me, I wouldn't do that either. I'd make my re-init script a sqlcmd script that looks something like:

:connect $(REPEATER_INSTANCE)
use [$(REPEATER_DB)];
declare arts cursor for
   select p.name as pub, a.name as art
   from sysarticles as a
   join syspublications as p
      on a.pubid = p.pubid;
open arts;
declare @p sysname, @a sysname;
while(1=1)
begin
   fetch next from arts into @p, @a
   if (@@fetch_status <> 0)
      break;
   exec sp_droparticle @publication = @p, @article @a;
end
close arts;
deallocate arts;

:connect $(PUBLISHER)
use [$(PUBLISHER_DB)];
--whatever script you use to create the publication here

Note: that's completely untested (I don't have replication set up at home), but should be pretty close.

Lastly (and rhetorically), why are you re-initializing so often? That should be a rare event. If it's not, you may have a configuration issue (eg if you're constantly lagging behind so far that you exceed the distributor retention, increase the distributor retention).