如何有效抓取SQL Server的BLOCKING信息

SQL Server允許並發操作，BLOCKING是指在某壹操作沒有完成之前，其他操作必須等待，以便於保證數據的完整性。BLOCKING的解決方法要查看BLOCKING的頭是什麽，為什麽BLOCKING頭上的語句執行的很慢。通常來講只要我們能找到BLOCKING頭上的語句，我們總能夠想出各種各種的辦法，來提升性能，緩解或解決BLOCKING的問題。

但是問題的關鍵是，我們不知道BLOCKING什麽時候會發生。用戶跟我們抱怨數據庫性能很差，等我們連上數據庫去查看的時候，那時候有可能BLOCKING可能就已經過去了。性能又變好了。或者由於問題的緊急性，我們直接重新啟動服務器以恢復運營。但是問題並沒有最終解決，我們不知道下次問題會在什麽時候發生。

BLOCKING問題的後果比較嚴重。因為終端用戶能直接體驗到。他們提交壹個訂單的時候，無論如何提交不上去，通常幾秒之內能完成的壹個訂單提交，甚至要等待十幾分鐘，才能提交完成。更有甚者，極嚴重的BLOCKING能導致SQL Server停止工作。如下面的SQL ERRORLOG所表示, 在短短的幾分鐘之內，SPID數據從158增長到694, 並馬上導致SQL Server打了壹個dump, 停止工作。我們很容易推斷出問題的原因是由於BLOCKING導致的，但是我們無法得知BLOCKING HEADER是什麽，我們必須要等下次問題重現時，輔之以工具，才能得知BLOCKING HEADER在做什麽事情。如果信息抓取時機不對，我們可能要等問題發生好幾次，才能抓到。這時候，客戶和經理就會有抱怨了。因為我們的系統是生產系統，問題每發生壹次，都會對客戶帶來損失。

2011-06-01 16:22:30.98 spid1931 Alert There are 158 Active database sessions which is too high.

2011-06-01 16:23:31.16 spid3248 Alert There are 342 Active database sessions which is too high.

2011-06-01 16:24:31.06 spid3884 Alert There are 517 Active database sessions which is too high.

2011-06-01 16:25:31.08 spid3688 Alert There are 694 Active database sessions which is too high.

2011-06-01 16:26:50.93 Server Using 'dbghelp.dll' version '4.0.5'

2011-06-01 16:26:50.97 Server **Dump thread - spid = 0, EC = 0x0000000000000000

2011-06-01 16:26:50.97 Server ***Stack Dump being sent to D:\MSSQL10.INSTANCE\MSSQL\LOG\SQLDump0004.txt

2011-06-01 16:26:50.97 Server * *******************************************************************************

2011-06-01 16:26:50.97 Server *

2011-06-01 16:26:50.97 Server * BEGIN STACK DUMP:

2011-06-01 16:26:50.97 Server * 06/01/11 16:26:50 spid 4124

2011-06-01 16:26:50.97 Server *

2011-06-01 16:26:50.97 Server * Deadlocked Schedulers

2011-06-01 16:26:50.97 Server *