但是問題的關鍵是，我們不知道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 *