We have a large sql 2008 distribution db (25 gb) where when the distribution clean up job runs, the CPU spikes up to 91%. We have 66 million rows in the last 3 days (our retention period is 72 hours) in the ms_repl_commands to have deleted. We have 11 publications going to our remote distributor and 4 of the publications have immediate_sync on and the rest do not. We notice that the msrepl_commands and mssubscriptions tables have indexes that are highly fragmented. We are planning to try a reorg tonight to see if that helps. I also just recompiled the proc sp_msdelete_publisherdb_trans (theory being that there are different code paths for publications with immediate_sync on and off) and the average I/Os went down but we still have 66 million rows of commands to delete. Our commands are getting to our subscribers so we are still servicing DML requests.
We also saw the following article:
http://www.databaseteam.org/1-ms-sql-server/fb589585367f06a1.html
I wanted to get some opinions on options at this point. Would it be safe to do with recompile hints on sp_msdelete_publisherdb_trans? Should we set all of our publications to immediate_sync off? I'm not sure about increasing the size of the number of commands from 2k to something else since we're already having CPU pressure. What about adding the update stats to the ms_msdelete_publisherdb_trans proc? I don't want to hack Microsoft code unless we feel comfortable doing that.
Thanks in advance!