對于資料庫運維人員來說建立session或者查詢時産生問題是正常情況，下面介紹一種很有效且不借助第三方工具的方式來解決類似問題。
最近開始接觸運維工作，是以自己總結一些方案便于不懂資料庫的同僚解決一些不太緊要的資料庫問題。類似方法很多理論也很多，我就不做深究，就是簡單寫一個方案，便于菜鳥使用的。
在Sql Server 中當一個資料庫會話中的事務正鎖定一個或多個其他會話事務想要讀取或修改的資源時，會産生阻塞(Blocking)。通常短時間的阻塞沒有問題，且是較忙的應用程式所需要的。然而，設計糟糕的應用程式會導緻長時間的阻塞，這就不必要地鎖定了資源，而且阻塞了其他會話讀取和更新它們。
為了更好說明，下面用一個例子來介紹。建立一個表并插入資料，然後建立不同的session，同僚阻塞session。具體的代碼截圖如下：
1.建立表Employee
2.插入測試資料
現在我們有了測試表，表中有12條資料，打開另一個查詢對話框在SSMS中（意味着重新建立了一個session）
3.在新的查詢視窗中首先要開啟事務，然後寫一個插入語句
在這個地方，我們能看到開啟了一個事務。但是沒有end tran 來終止事務，是以事務狀态為“open”，現在運作腳本來看一下目前看起的運作處于“open”狀态的session。
現在能夠看到如上圖展示一樣，運作的查詢正在open狀态的session。我們執行了這個指令但是沒有完結它，DBA會聯系這個session的建立者來完成事務，或者復原事務。
現在讓我們建立另一個session，更新一條記錄并且不送出，即讓查詢session的狀态為“open”。是以在新的查詢視窗中 寫一個語句來執行如下：
這裡會看到系統正在運作後沒有完成語句的狀态（因為上一個事務沒有關閉導緻表鎖，這個不能插入），現在可以在另外的視窗查詢一下阻塞的情況，如下檢查阻塞的session。
如上所示，阻塞的session ID是58，由于我們更新查詢導緻阻塞了54的執行，54就是我們插入資料未送出的批處理。
現在我們能搞清楚阻塞的原因，也就可以從容解決阻塞了。
在了解業務的情況下，可以直接使用kill session ID的語句來終止某個阻塞的session。
在執行的事務的起始加入“set lock_timeout 1000” 語句，這表示如果阻塞超過1000毫秒，這個請求将被終止。
復原或者送出事務。這個就不細說了。
下面是所有語句的代碼：
本文轉自zsdnr 51CTO部落格，原文連結：http://blog.51cto.com/12942149/1944650，如需轉載請自行聯系原作者