數據庫產生阻塞（Blocking）的本質原因 ：SQL語句連續持有鎖的時間過長 ，數目過多， 粒度過大。阻塞是事務隔離帶來的副作用，它是不可避免的，而且是一個數據庫系統常見的現象。 但是阻塞的時間和出現頻率要控制在一定的范圍內，阻塞持續的時間過長或阻塞出現過多（過於頻繁），就會對數據庫性能產生嚴重的影響。
很多時候，DBA需要知道數據庫在出現性能問題時，有沒有發生阻塞？ 什麼時候開始的？發生在那個數據庫上？ 阻塞發生在那些SQL語句之間？ 阻塞的時間有多長？ 阻塞發生的頻率？ 阻塞有關的連接是從那些客戶端應用發送來的？.......
如果我們能夠知道這些具體信息，我們就能迅速定位問題，分析阻塞產生的原因， 從而找出出現性能問題的根本原因，並根據具體原因給出相應的解決方案（索引調整、優化SQL語句等）。
查看阻塞的方法比較多， 我在這篇博客MS SQL 日常維護管理常用腳本(二)裡面提到查看阻塞的一些方法：
方法1：查看那個引起阻塞，查看blk不為0的記錄，如果存在阻塞進程，則是該阻塞進程的會話 ID。否則該列為零。
EXEC sp_who active
方法2：查看那個引起阻塞，查看字段BlkBy，這個能夠得到比sp_who更多的信息。
EXEC sp_who2 active
方法3：sp_lock 系統存儲過程，報告有關鎖的信息，但是不方便定位問題
方法4：sp_who_lock存儲過程
方法5：右鍵服務器-選擇“活動和監視器”，查看進程選項。注意“任務狀態”字段。
方法6：右鍵服務名稱-選擇報表-標准報表-活動-所有正在阻塞的事務。
但是上面方法，例如像sp_who、 sp_who2，sp_who_lock等，都有或多或少的缺點：例如不能查看阻塞和被阻塞的SQL語句。不能從查看一段時間內阻塞發生的情況等；沒有顯示阻塞的時間....... 我們要實現下面功能：
1: 查看那個會話阻塞了那個會話
2：阻塞會話和被阻塞會話正在執行的SQL語句
3：被阻塞了多長時間
4：像客戶端IP、Proagram_Name之類信息
5：阻塞發生的時間點
6：阻塞發生的頻率
7：如果需要，應該通知相關開發人員，DBA不能啥事情都包攬是吧，那不還得累死，總得讓開發人員員參與進來優化（有些問題就該他們解決），多了解一些系統運行的具體情況，有利於他們認識問題、解決問題。
8：需要的時候開啟這項功能，不需要關閉這項功能
於是為了滿足上述功能，有了下面SQL 語句
SELECT wt.blocking_session_id AS BlockingSessesionId
,sp.program_name AS ProgramName
,COALESCE(sp.LOGINAME, sp.nt_username) AS HostName
,ec1.client_net_address AS ClientIpAddress
,db.name AS DatabaseName
,wt.wait_type AS WaitType
,ec1.connect_time AS BlockingStartTime
,wt.WAIT_DURATION_MS/1000 AS WaitDuration
,ec1.session_id AS BlockedSessionId
,h1.TEXT AS BlockedSQLText
,h2.TEXT AS BlockingSQLText
