SQL查詢數據庫死鎖

     SELECT   spid,  kpid,  blocked,  waittime AS 'waitms', 
  lastwaittype,   DB_NAME(dbid)AS DB,  
  waitresource,   open_tran,
 hostname,[program_name],
 hostprocess,loginame,
 [status]
 FROM sys.sysprocesses WITH(NOLOCK) 
 WHERE    kpid>0  AND  [status]<>'sleeping'  AND spid>50 and blocked>0






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負荷過重沒有及時處理用戶的併發請求

exec sp_lock;---查詢所有進程鎖

 exec sp_lock 55 -- 查詢指定進程55的鎖




select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName
from sys.dm_tran_locks
where resource_type='OBJECT' and OBJECT_NAME(resource_associated_entity_id) is not null



--輸出引起死鎖的操作
DBCC INPUTBUFFER (@spid)

 

 

 

 declare @spid int
Set @spid = 53 --要Kill掉的鎖表進程
declare @sql varchar(1000)
set @sql='kill '+cast(@spid as varchar)
exec(@sql)

 

 新開兩個查詢窗口 

 

BEGIN TRANSACTION--開始事務 創造鎖表的操作

update [dbo].[Archer]     set [NAME] ='00000'  where id='1'

WAITFOR DELAY '02:00'; 

 

select * from [Archer] where id='1'

 

 

 

轉自  https://blog.csdn.net/weixin_34001430/article/details/86006022