在生產(chǎn)環(huán)境下，有時公司客服反映網(wǎng)頁半天打不到，除了在瀏覽器按F12的Network響應(yīng)來排查，確定web服務(wù)器無故障后。就需要檢查數(shù)據(jù)庫是否有出現(xiàn)阻塞

當(dāng)時數(shù)據(jù)庫的生產(chǎn)環(huán)境中主表數(shù)據(jù)量超過2000w,子表數(shù)據(jù)量超過1億，且更新和新增頻繁。再加上做了同步鏡像，很消耗資源。

這時就要新建一個會話，大概需要了解以下幾點：

• 1.當(dāng)前活動會話量有多少？
• 2.會話運行時間？
• 3.會話之間有沒有阻塞？
• 4.阻塞時間 ?

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

一. 阻塞查詢 sp_lock

執(zhí)行 exec sp_lock  下面列下關(guān)鍵字段

spid 是指進程ID，這個過濾掉了系統(tǒng)進程，只展示了用戶進程spid>50。

dbid 指當(dāng)前實例下的哪個數(shù)據(jù)庫 , 使用DB_NAME() 函數(shù)來標識數(shù)據(jù)庫

type 請求鎖住的模式

mode 鎖的請求狀態(tài)

• GRANT：已獲取鎖。
• CNVRT：鎖正在從另一種模式進行轉(zhuǎn)換，但是轉(zhuǎn)換被另一個持有鎖（模式相沖突）的進程阻塞。
• WAIT：鎖被另一個持有鎖（模式相沖突）的進程阻塞。

總結(jié)：當(dāng)mode 不為GRANT狀態(tài)時， 需要了解當(dāng)前鎖的模式，以及通過進程ID查找當(dāng)前sql 語句 

例如當(dāng)前進程ID是416，且mode狀態(tài)為WAIT 時，查看方式 DBCC INPUTBUFFER(416)

用sp_lock查詢顯示的信息量很少，也很難看出誰被誰阻塞。所以當(dāng)數(shù)據(jù)庫版本為2005及以上時不建議使用。

 二.阻塞查詢  dm_tran_locks 

SELECT
t1.resource_type,
t1.resource_database_id,
t1.resource_associated_entity_id,
t1.request_mode,
t1.request_session_id,
t2.blocking_session_id
FROM sys.dm_tran_locks as t1
INNER JOIN sys.dm_os_waiting_tasks as t2
ON t1.lock_owner_address = t2.resource_address;