數據庫產生阻塞（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