Monday, February 20, 2012

Merge replication and deadlocks

Hi,
I have an application that have a single publisher with 7 anonymous merge
subscriber (SQL2000). Distributor is in my publication server.
I have 7 publications (one db) - most of them synchronizing every half an
hour or so.
However, I have a publication that needs to be as up-to-date in every server
at all times. So, I am running the agent continuosly in each subscriber.
Usually it works ok, but sometimes, when there is a big batch update on the
tables belonging to that publication all merge agents block themselves
trying to process the replication.
I tried using the "Concurrent Merge Processes" setting to limit the number
of processes running, but it seemed to me that processes waiting in line
blocked other processes - in fact I got to a point where *all* my
subscribers said at the same time that they were waiting in the queue
because otherwise they would exceed the limit of concurrent processes.
The "Concurrent Merge Processes" settings is what I consider should fix my
problem - sadly it makes it worse. I could change the profile of the agents
but not sure where I should start on (and it is not easy to know if things
are better or worse either).
Maybe moving the distributor to another server?
Well... maybe you can point to some place where there is information about
replication optimization...
Thanks, Jos Araujo.
you have to edit your agent properties and set StartQueueTimeout to
something like 60.
You might also want to reindex msmerge_contents, tombstone, and genhistory
nightly.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Jos Araujo" <josea@.mrcinc.com> wrote in message
news:uXorChWtFHA.2892@.TK2MSFTNGP10.phx.gbl...
> Hi,
> I have an application that have a single publisher with 7 anonymous merge
> subscriber (SQL2000). Distributor is in my publication server.
> I have 7 publications (one db) - most of them synchronizing every half an
> hour or so.
> However, I have a publication that needs to be as up-to-date in every
server
> at all times. So, I am running the agent continuosly in each subscriber.
> Usually it works ok, but sometimes, when there is a big batch update on
the
> tables belonging to that publication all merge agents block themselves
> trying to process the replication.
> I tried using the "Concurrent Merge Processes" setting to limit the number
> of processes running, but it seemed to me that processes waiting in line
> blocked other processes - in fact I got to a point where *all* my
> subscribers said at the same time that they were waiting in the queue
> because otherwise they would exceed the limit of concurrent processes.
> The "Concurrent Merge Processes" settings is what I consider should fix my
> problem - sadly it makes it worse. I could change the profile of the
agents
> but not sure where I should start on (and it is not easy to know if things
> are better or worse either).
> Maybe moving the distributor to another server?
> Well... maybe you can point to some place where there is information about
> replication optimization...
> Thanks, Jos Araujo.
>
|||Thanks! setting the timeout really helped.
Jos.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:Oto7FQbtFHA.2076@.TK2MSFTNGP14.phx.gbl...
> you have to edit your agent properties and set StartQueueTimeout to
> something like 60.
> You might also want to reindex msmerge_contents, tombstone, and genhistory
> nightly.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Jos Araujo" <josea@.mrcinc.com> wrote in message
> news:uXorChWtFHA.2892@.TK2MSFTNGP10.phx.gbl...
> server
> the
> agents
>

No comments:

Post a Comment