Merge Replication Problem

We have setup merge replication on a production server/database that
is also referenced by our web application. The replication works with
a remote, disconnected application that uses MSDE as it's back-end.
The replication works correctly, but we had to set aside a range of
PKIDs for each table because we were getting duplicate primary key
errors during synchronization of data. Unfortunately, this causes
problems with the web application. After the range of IDs runs out,
the web application can no longer update the database.
Has anyone else run into this problem? Is there a way around using
this method that will still remove the chance of getting a duplicate
primary key error during synchronization? Is setting aside a range of
IDs the only method for avoiding this error?
Thanks in advance
Dan Broomall
Please see my previous answer.
Regards,
Paul
|||Hi,
I have recently implemented merge replication between 1 publisher and 1
subscriber, with push subscription for every 10 minute interval. the
replication went fine, but we are experiencing huge performance problems.
most application users are not able to work on the primary server. We have
temporarily disabled the merge agents, but still the performance is not
boosted. Both publisher and distributor are on one machine with log files on
different drives. What should be the counters to monitor performance?
Also, the clients connect using the http port. the webserver is also on the
same machine as the sql server.
"Paul Ibison" wrote:

> Please see my previous answer.
> Regards,
> Paul
>
>
|||ST,
as you have disabled your merge agents, this side of things is obviously not
the cause. However, the replication triggers will still fire so this is an
overhead. For a general slowness of the sql server, you could look at
processor, memory and disk counters in Performance Monitor. Several articles
list the counters you might start with, so I won't list them here, but this
is a good starting point:
http://www.sql-server-performance.co...ce_article.asp
HTH,
Paul Ibison
|||Thankyou for responding. I have 1 more question, Do we have to replicate the
views and stored procedures compulsarily. I decided not to in the end because
all we really need is the data to replicate. Now i am thinking if the
execution of the stored procedures is causing the performance overhead.
Please tell me if by replicating the stored procedures and views, will i have
a performance boost. I want to do it if it is absolutely necessary.
Thanks
S.T
"Paul Ibison" wrote:

> ST,
> as you have disabled your merge agents, this side of things is obviously not
> the cause. However, the replication triggers will still fire so this is an
> overhead. For a general slowness of the sql server, you could look at
> processor, memory and disk counters in Performance Monitor. Several articles
> list the counters you might start with, so I won't list them here, but this
> is a good starting point:
> http://www.sql-server-performance.co...ce_article.asp
> HTH,
> Paul Ibison
>
>
|||ST,
I'm not sure which stored procedures and views you are referring to. In
merge you can replicate them, but if you use transactional you can not only
replicate the TSQL - entries in sysobjects, syscomments, syscolumns etc -
you can also choose to replicate the execution of stored procedures. Maybe
this is what you are looking for? I'm not too sure how this relates to your
performance issues however. Please can you expand a little.
TIA,
Paul Ibison
|||When i setup the merge replication, i just selected the Tables to be
published, i didnot select the user stored procedures and views that are used
by the appliaction database. i just wanted to publish as little as possible
since i was doing the no sync option and the subscriber was already having
the stored procedures and views associated with the tables. Now, I am
thinking if in anyway the merge process was not having any information about
the stored procedure execution, it might have made the performance slowdown.
Also, i noticed that the I/O reads and write have increased heavily and the
data drive has got highly fragmented. Please advise
Thanks
ST
"Paul Ibison" wrote:

> ST,
> I'm not sure which stored procedures and views you are referring to. In
> merge you can replicate them, but if you use transactional you can not only
> replicate the TSQL - entries in sysobjects, syscomments, syscolumns etc -
> you can also choose to replicate the execution of stored procedures. Maybe
> this is what you are looking for? I'm not too sure how this relates to your
> performance issues however. Please can you expand a little.
> TIA,
> Paul Ibison
>
>
|||ST,
merge replication doesn't replicate the execution of stored procedures -
just the TSQL on initialization, (and not when the definitions change
either).
If you have disk fragmentation, then (out of hours) I'd reindex all the
tables then defragment the disk. Backup everything before doing this to an
external device. It sounds like you have some benchmark comparisons so
running the same counters afterwards should show a noticeable difference.
HTH,
Paul Ibison