@max_concurrent_merge

I have a merge publication (dynamically filtered). Subscriptions are
all anonymous (all run at the subscriber) and run continuously.
What effect does the publication option @.max_concurrent_merge have on
a replication topology such as this? Also known as the "Publication
Properties | Subscriptions tab | "Limit the number of concurrent merge
processes to the following" setting . . .
I noticed in a test environment when I set it to 1 my 2 anonymous
subscribers are still able to connect and reach "no data to be
merged". . . does setting this physically limit the number of "merge
activity" or the number of "merge agent connections" or something
else? I believe my testing shows it doens't limit the connections, but
maybe it does something w/ the "merge activity" under the hood?
Any help is greatly appreciated . . .
Matt
It limits the number of simultaneous merge agents that can run. The default
for this is 10, so if you have 20 subscribers running continuously, only 10
of them would be running simultaneously and the rest would be queued.
For 2 subscribers you should not have to worry about it.
Please refer to this link for a more indepth discussion of this.
http://www.microsoft.com/technet/pro.../mergperf.mspx
"Matt" <la_la_looey@.yahoo.com> wrote in message
news:a0313d3.0404210946.4e767ee9@.posting.google.co m...
> I have a merge publication (dynamically filtered). Subscriptions are
> all anonymous (all run at the subscriber) and run continuously.
> What effect does the publication option @.max_concurrent_merge have on
> a replication topology such as this? Also known as the "Publication
> Properties | Subscriptions tab | "Limit the number of concurrent merge
> processes to the following" setting . . .
> I noticed in a test environment when I set it to 1 my 2 anonymous
> subscribers are still able to connect and reach "no data to be
> merged". . . does setting this physically limit the number of "merge
> activity" or the number of "merge agent connections" or something
> else? I believe my testing shows it doens't limit the connections, but
> maybe it does something w/ the "merge activity" under the hood?
> Any help is greatly appreciated . . .
> Matt
|||2 subscribers was my test lab . . . I actually have over 100.
I believe after extended testing, I see this setting simply controls
the number of connections . . . so, if you have your agent set to run
continuously, other agents would "starve."
"Hilary Cotter" <hilaryk@.att.net> wrote in message news:<#HF4BTBKEHA.2556@.TK2MSFTNGP11.phx.gbl>...[vbcol=seagreen]
> It limits the number of simultaneous merge agents that can run. The default
> for this is 10, so if you have 20 subscribers running continuously, only 10
> of them would be running simultaneously and the rest would be queued.
> For 2 subscribers you should not have to worry about it.
> Please refer to this link for a more indepth discussion of this.
> http://www.microsoft.com/technet/pro.../mergperf.mspx
>
> "Matt" <la_la_looey@.yahoo.com> wrote in message
> news:a0313d3.0404210946.4e767ee9@.posting.google.co m...
|||not so, they are queued until the others finished. sort of like a round
robin. Check out the link for more info.
"Matt" <la_la_looey@.yahoo.com> wrote in message
news:a0313d3.0404220441.15777f5c@.posting.google.co m...
> 2 subscribers was my test lab . . . I actually have over 100.
> I believe after extended testing, I see this setting simply controls
> the number of connections . . . so, if you have your agent set to run
> continuously, other agents would "starve."
>
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
news:<#HF4BTBKEHA.2556@.TK2MSFTNGP11.phx.gbl>...[vbcol=seagreen]
default[vbcol=seagreen]
10[vbcol=seagreen]
http://www.microsoft.com/technet/pro.../mergperf.mspx[vbcol=seagreen]

@force_reinit_subscription

Hi,

If I add or remove a merge article from a publication and I specify the @.force_reinit_subscription = 1, will this force a new snapshot to be sent to all subscribers? If it does, will it apply the who snapshot as it did when the subscription was created or is it clever enough to work out what bits are different?

Thanks for your help

Graham

if you drop an article, and you force reinit and snapshot generation, depending on exactly what needs to be generated, you may be required to create a new snapshot (and dynamic snapshot), and apply new snapshot. i.e. if you drop a static article (not filtered, nor not participating in any joins), you may not need to generate a snapshot. But if you the article is a filtered article, or participates in a join, the snapshot may need to be reapplied.

So yes, it's clever :)