sql server 阻塞查詢

原文: sql server 阻塞查詢

 在生產環境下，有時公司客服反映網頁半天打不到，除了在瀏覽器按F12的Network響應來排查，肯定web服務器無端障後。就須要檢查數據庫是否有出現阻塞

當時數據庫的生產環境中主表數據量超過2000w,子表數據量超過1億，且更新和新增頻繁。再加上作了同步鏡像，很消耗資源。

這時就要新建一個會話，大概須要瞭解如下幾點：

1.當前活動會話量有多少？

2.會話運行時間？

3.會話之間有沒有阻塞？

4.阻塞時間 ?

查詢阻塞的方法有不少。有sql 2000 的sp_lock, 有sql 2005及以上的dmv

一. 阻塞查詢 sp_lock

      執行 exec sp_lock  下面列下關鍵字段

      spid 是指進程ID，這個過濾掉了系統進程，只展現了用戶進程spid>50。

      dbid 指當前實例下的哪一個數據庫 , 使用DB_NAME() 函數來標識數據庫

      type 請求鎖住的模式

      mode 鎖的請求狀態

                     GRANT：已獲取鎖。

                     CNVRT：鎖正在從另外一種模式進行轉換，可是轉換被另外一個持有鎖（模式相沖突）的進程阻塞。
                     WAIT：鎖被另外一個持有鎖（模式相沖突）的進程阻塞。

     總結：當mode 不爲GRANT狀態時， 須要瞭解當前鎖的模式，以及經過進程ID查找當前sql 語句 

                例如當前進程ID是416，且mode狀態爲WAIT 時，查看方式 DBCC INPUTBUFFER(416)

               用sp_lock查詢顯示的信息量不多，也很難看出誰被誰阻塞。因此當數據庫版本爲2005及以上時不建議使用。

 二.阻塞查詢  dm_tran_locks         

 1 SELECT 
 2 t1.resource_type,
 3 t1.resource_database_id,
 4 t1.resource_associated_entity_id,
 5 t1.request_mode,
 6 t1.request_session_id,
 7 t2.blocking_session_id
 8 FROM sys.dm_tran_locks as t1
 9 INNER JOIN sys.dm_os_waiting_tasks as t2
10 ON t1.lock_owner_address = t2.resource_address;

     上面查詢只顯示有阻塞的會話， 關注blocking_session_id 也就是被阻塞的會話ID，一樣使用DBCC INPUTBUFFER來查詢sql語句

三.阻塞查詢 sys.sysprocesses

 1 SELECT 
 2 spid,
 3 kpid,
 4 blocked,
 5 waittime AS 'waitms', 
 6 lastwaittype, 
 7 DB_NAME(dbid)AS DB,  
 8 waitresource, 
 9 open_tran,
10 hostname,[program_name],
11 hostprocess,loginame,
12 [status]
13 FROM sys.sysprocesses WITH(NOLOCK) 
14 WHERE    kpid>0  AND  [status]<>'sleeping'  AND spid>50

  sys.sysprocesses  能顯示會話進程有多少， 等待時間， open_tran有多少事務， 阻塞會話是多少. 總體內容更爲詳細。
  關鍵字段說明:

       spid 會話ID（進程ID），SQL內部對一個鏈接的編號，通常來說小於50

　　kipid 線程ID
　　blocked: 阻塞的進程ID， 值大於0表示阻塞, 值爲自己進程ID表示io操做
　　waittime:當前等待時間（以毫秒爲單位）。
　　open_tran: 進程的打開事務數
　　hostname:創建鏈接的客戶端工做站的名稱
　　program_name 應用程序的名稱。
　　hostprocess 工做站進程 ID 號。
　　loginame 登陸名。
　　[status]
　　　　running = 會話正在運行一個或多個批
　　　　background = 會話正在運行一個後臺任務，例如死鎖檢測
　　　　rollback = 會話具備正在處理的事務回滾
　　　　pending = 會話正在等待工做線程變爲可用
　　　　runnable = 會話中的任務在等待,由scheduler來運行的可執行隊列中。(重要)
　　　　spinloop = 會話中的任務正在等待調節鎖變爲可用。
　　　　suspended = 會話正在等待事件（如 I/O）完成。(重要)
　　　　sleeping = 鏈接空閒

              wait resource 格式爲 fileid:pagenumber:rid 如(5:1:8235440)

              kpid=0, waittime=0 空閒鏈接

              kpid>0, waittime=0 運行狀態
              kpid>0, waittime>0 須要等待某個資源，才能繼續執行,通常會是suspended（等待io）
              kpid=0, waittime=0 但它仍是阻塞的源頭，查看open_tran>0 事務沒有及時提交。

              若是blocked>0，但waittime時間很短，說明阻塞時間不長，不嚴重              若是status 上有好幾個runnable狀態任務，須要認真對待。 cpu負荷太重沒有及時處理用戶的併發請求