October 16, 2008 at 10:34 am
The merge history table is not cleaning up historical records that is older than the retention period of 48 hours. This is causing the history purge job for replication to have high IO.
EXEC dbo.sp_MShistory_cleanup @history_retention = 48
I merge publication has a push subscriber with a default retention period of 14 days in continuous mode. I am also polling every 2 seconds for changes.
I am looking to understand what controls when records get purge from the MSmerge_History table and how I can get around this.
Need a little help.
December 3, 2010 at 4:04 am
I have the same problem. Running SQL 2005sp2 Merge replication (Push). I noticed Distribution.MDF was growing larger that I would expect. I was missing the task 'Agent history clean up: distribution' so I created then ran the task which took about 1 minute to complete but made no difference. I then found MSmerge_History contained 2883869 rows. It doesn’t look like old entries are being removed - I though the task mentioned should maintain this.
I’m now looking to see if replication is running correctly, as rep monitor shows 90% initialised I would expect this to say 100% - although replication is continuous. I’m thinking data is failing to replicate resulting in MSmerge_History / Distribution.MDF growing but not sure how to resolve. I’m trying to avoid taking a new snapshot.
Did you manage to resolve this issue?
March 9, 2011 at 5:08 am
I have managed to clean out msmerge_history. This table within the distribution database was 7GB containing 10m records and growing. Running the SQL maint task;
agent history clean up: distribution which executes the following on a scheduled basis;
EXEC dbo.sp_MShistory_cleanup @history_retention = 48
didnt seem to be doing anything. I then ran this manually (changing the 48 to 1)
EXEC dbo.sp_MShistory_cleanup @history_retention = 1
and msmerge_history was reduced to around 1000 entries. This has resolved my problem. I just dont understand why changing from 48 hours to 1 cleared this table. I assume the 48 is hours, unless this can be changed to days as this is the only explanation for this. either way it deleted the old data from this table so I fixed the problem but don’t know why.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply