In a merge replication application with 100 subcribers the merge process is
generating large numbers of locks on the published db and causing
performance problems.
One suggestion was that we subscribe all external (VPN on ADSL) merge
subscribers to a subscribed copy of the database created explicitly for this
purpose, thereby reducing load on the primary db. Any comments? or has
anyone implemented a similar scheme and found it beneficial?
This is a good approach. You should try to identify where the locking is
coming from. For instance if you try to modify/manage your publications
using EM this can cause a large amount of locking. So use the procs if
possible.
Also use pull if you can. Then stagger your agents to run non-continuously
at different times.
"Tony Toker" <xyzzy@.identic.co.uk> wrote in message
news:cqbln8$dp4$1$8302bc10@.news.demon.co.uk...
> In a merge replication application with 100 subcribers the merge process
is
> generating large numbers of locks on the published db and causing
> performance problems.
> One suggestion was that we subscribe all external (VPN on ADSL) merge
> subscribers to a subscribed copy of the database created explicitly for
this
> purpose, thereby reducing load on the primary db. Any comments? or has
> anyone implemented a similar scheme and found it beneficial?
>
>
Friday, March 9, 2012
Republishing a subscribed database
Labels:
application,
database,
isgenerating,
locks,
merge,
microsoft,
mysql,
numbers,
oracle,
process,
published,
replication,
republishing,
server,
sql,
subcribers,
subscribed
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment