September 14, 2010 at 4:33 am
I have been investigating a problem where SQL 2005 Merge replication causes the subscriptions server CPU to run at 100%. The publication/distribution servers CPU is ok.
When stopping/disable the replication job the subscriptions CPU drops from 100% to a 1-5% hence replication is causing a problem.
I trid to reinitialise and validate the subscription choosing to create a new snapshot and then run the replication job but this made no difference.
when viewing replication monitor no replication was in progress, nor were there any errors.
I ran profiler and the ‘sp_MSenumgenerations90’ (runs Proc_mergereplicationcleanup) appear lots. After a google search which pointed me in the direction of the SQL ‘merge clan up job’ and also talked about ‘subscription expiration’ within the general properties of the publication.
Within the properties of my publication the subscription expiration was set to
•Subscription never expire.
rather than the default
•Subscriptions expire and mau be dropped if not synchronised in the follow interval, which is 14 days by default.
I changed my subscription to the default thinking this might be causing some sort of issue.
I then looked at the ‘merge clan up job ‘ and viewed the history which showed the job had been running ok once a month and usually takes under a minute to complete. The last successful run was the beginning of this month, 1st September.
The problem with 100% CPU was discovered at the weekend 11/12th September. I manually ran this job and it took 24 minutes to complete.
After it completed I started replication and the problem appears to have been resolved, CPU spiked a little as you would expect for an initial replication merge sync then settled.
My question is does running, NEVER EXPIRE causes this problem and should any other jobs be required and can it cause problems with the merge cleanup job and make it not run correctly?
July 9, 2013 at 9:11 am
Seems to be working but I am using 2008
Jamie
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply