Takeaway: You’ve detected, analyzed and understood blocked processes that have happened on your machine. What can you do to avoid this blocking in the future?
Those who know me well, know I’ve started a project that helps database professionals analyze the blocked process reports that SQL Server produces. I’ve talked about it before:
- The Blocked Process Report Viewer codeplex project where it’s hosted.
- The original blog post that explains how to use it.
- The last blog post that explains when to use it (with fun flowcharts).
But I got an excellent comment from Wallace Houston. He writes:
“What I’m looking for is “what to do” when blocks are already identified. I want to try to prevent them. In other words, how to modify my code in such a way as to avoid as many blocks as possible.”
That’s an excellent question. Wallace went on to talk about a “chain reaction” of blocking where everything locked up. Man, I’ve been there and it can be disastrous. It sometimes seems like the only thing to do is to kill the lead blocker’s process. And that feels like giving up.
So after giving it some thought. I came up with this (slightly reworded from my reply to Wallace). These are actions you can take to avoid blocking in the future.
This is Next:
- If at all possible, tune the lead blocker. If a lead blocker can get take its lock and let it go immediately then there’s no more blocking.
- Avoid transactions if you don’t need them (but don’t be afraid of them if you do).
- Pick the nicest isolation level for your transaction. Read committed is nicer than repeatable read is nicer than serializable.
- If you can get away with it, maybe put the query that’s the lead blocker in a transaction that uses “snapshot isolation”. It uses a bit of tempdb resources, but it’s awesome for concurrency problems.
- There’s table lock hints (readpast, nolock, holdlock) for more targeted locking, but really you want to understand who’s doing what before you go down that road.
- I’m not ashamed to say that I’ve used isolation level “read uncommitted” which is equivalent to the NOLOCK table hint. Especially when the caller can tolerate the very very rare cases of inconsistency that might result. NOLOCK is easy and you can’t argue with results – it works – but snapshot isolation is preferred because it is guaranteed to be consistent (if not current).
Progress on my Blocked Process Report Viewer
- fixed a few bugs
- added some documentation (which you’ve already seen if you read this blog).
- added some SQL Profiler template files and SQL Trace scripts to help collect BPR
- added a quick and dirty test suite.
It’s pretty much good to go and release as version 1.0. But I still want to add features that makes it easier to analyze.
Stay tuned and happy block busting!