July 20, 2012 at 7:45 am
We have a merge replication scenario with pull subscriptions. Currently there is only one publication but we are adding a new publication, where some articles are going ot be common. Some of the common articles are going to be download only. but some are updateable on both sides. With this information, can someone please point me the right direction to achieve this? Obvious goal is to do it right the first time even if the solution seems eccentric. Thank you.
July 31, 2012 at 7:55 am
the best practice here is to not put an article in multiple pulbications. It's bad for performance. Breal it up into smaller publications if you have to and send multiple publications to the same subscribers, but don't do what you propose.
July 31, 2012 at 4:32 pm
So for a bidirectional(but always inserted at the subscriber) article, across publications, even if it is guaranteed that a uniquely identified row exists at only one subscriber (other than the publisher of course), you think it still might cause performance bottleneck? This is a filtered article in both publications.
As an example, let's say this is a 'UserLog' table. only subscribers log and not the publishers. There are two different publications, but only one 'UserLog' table, so we got to include it in both publications. We filter subscriptions by userid, so all datasets are disjoint wrt userid.
Do you think this still is a performance bottleneck?
July 31, 2012 at 5:13 pm
When it an article is in multiple publications, it is tracked separately for each one. So every update to the table will be tracked multiple times. This will cause there to be more records in the tracking tables. You are better off putting that table into a publication by itself and subscribing both subscriptions to it.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply