觸發器導致的一個表的死鎖問題

事務(進程 ID 450)與另一個進程被死鎖在 鎖 資源上，並且已被選作死鎖犧牲品。請重新運行該事務

 這行紅字大家都會遇到，有了這個問題 可以開啟死鎖跟蹤，由於當時沒有開， 首先執行下

select * from sys.sysprocesses  where spid>=50 and blocked>0

找到對應的鎖（blocked）與被鎖（spid）的關系，下面 就簡單多了：

通過 DBCC INPUTBUFFER(@SPID) –@SPID 對應進程號

或者通過

SELECT s2.text,* FROM sys.sysprocesses S1  CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2  WHERE SPID=@spid

找到對應的語句。

到這里知道執行哪些存儲過程導致的；

問題奇怪的是 這個鎖，會慢慢消失，所以有區別我們常見的一條死鎖導致整個數據庫大面積癱掉，所以上面的只算是發現是執行上面的語句導致死鎖的。

 

先不要着急，由於和開發確定了，近期沒有新業務和新產品上線，所以有麻煩他們那邊重新執行下那個任務，以彌補之前沒有開啟的死鎖跟蹤，

然后我看下后台資源的等待信息；
  SELECT TOP 100
  [cpu_time],
  [session_id],
[request_id],
[start_time] AS '開始時間',
  [status] AS '狀態',
[command] AS '命令',
dest.[text] AS 'sql語句',
DB_NAME([database_id]) AS '數據庫名',
[blocking_session_id] AS '正在阻塞其他會話的會話ID',
[wait_type] AS '等待資源類型',
[wait_time] AS '等待時間',
[wait_resource] AS '等待的資源',
[reads] AS '物理讀次數', [writes] AS '寫次數',
[logical_reads] AS '邏輯讀次數',
[row_count] AS '返回結果行數'
FROM sys.[dm_exec_requests] AS der
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50 -- AND DB_NAME(der.[database_id])='gposdb' 
ORDER BY [cpu_time] DESC

找到資源等待類型：PAG: 7:1:6861400 是這個頁面的ID 鎖住了

然后我們通過這個頁面ID 找到對應的表ID：

DBCC TRACEON(3604)
 

DBCC PAGE(7,   --數據庫ID : 10 
          1,    --文件ID: 1 
          6861400,  --頁ID: 188 
          3) WITH TABLERESULTS  

下面是執行的結果 找到對應的object_id

m_pageId = (1:6861400)               m_headerVersion = 1                  m_type = 2
m_typeFlagBits = 0x80                m_level = 0                          m_flagBits = 0x200
m_objId (AllocUnitId.idObj) = 3882   m_indexId (AllocUnitId.idInd) = 256 
Metadata: AllocUnitId = 72057594292338688                                
Metadata: PartitionId = 72057594260160512                                 Metadata: IndexId = 31
Metadata: ObjectId = 609437245       m_prevPage = (0:0)                   m_nextPage = (1:6861401)
pminlen = 3                          m_slotCnt = 816                      m_freeCnt = 2425
m_freeData = 4135                    m_reservedCnt = 0                    m_lsn = (302375:1725:2)
m_xactReserved = 0                   m_xdesId = (0:0)                     m_ghostRecCnt = 0
m_tornBits = 344815137    

通過id  找到對應 數據庫db_id（7）對應的表名：
SELECT NAME FROM SYSOBJECTS WHERE ID=609437245      

NAME=’[business].[Business]’

從上面的表可以看到是公司核心表了，所有公司訂單業務號都是出自這張表；

其實當時以為是新上線的產品，導致業務量變大，或者排它鎖頻率增高，先以該邏輯為先，后來研發說一直都沒問題，昨天出的問題，然后我開始針對這張表仔細研究下；

 

當我再次執行等待資源的時候才看到了端倪，大家都知道觸發器是性能殺手之一，當別的LCK_M_U 時候觸發器也是需要等待的；事物隔離

 

說實話這個觸發器，我並不知情的， 然后我把這個禁用掉，問題就解決了；針對business 上的觸發器；