We have been having issues lately with CRM due to sql blocking. After doing some digging, I ran across this article. It mentions the AX product, rather than just regular CRM, but Im curious if this applies or not?
In our case, this setting is off...so if this applies, it might explain why the constant blocking that comes up during even moderate load
I confirm that we could reduce the number of deadlocks significantly by that. But as Josh mentioned, you should try to find out and eliminate the root cause. In our project, some long running interfaces (built with Scribe) causes these deadlocks.
Dynamics CRM Blog | LinkedIn Profile
Not officially, but a common recommendation (also directly from MS) to improve performance and reduce db-locks.
RCSI isn't a setting to improve performance. If you are going to turn on RCSI you need to understand the implications if doing so. It will greatly increase the load on your tempdb and you need to account for that. Every row in your db is versions with RCSI it is NOT the same as setting transaction isolation level = read committed.
Here is a brief article about RCSI you should read and understand. msdn.microsoft.com/.../tcbchxcb(v=vs.110).aspx
I would also look to understand what your blocking issue is caused by. Is it a particular table? User? Application? Time of day?
Joshua Thompson Sr. Associate - Technology Services
Josh, I totally agree with your statement.
My answer was a bit short, and I know the article you mentioned.
And yes, first of all you should find the root cause of the blocking issue(s) and resolve them if possible.
However, in some cases we saw massive performance improvements. Mostly when a lot of scheduled interface jobs and/or a lot of plugins worked on the same entities.
Peter, my reply was more directed at the OP than you, sorry if it came across the other way around.
Josh, don't worry, I did not construed it this way :-)
This article on Technet as part of other Dynamics CRM-specific optimization steps, suggests enabling Read Committed Snapshot isolation to avoid deadlocks