触发器导致的一个表的死锁问题

事务(进程 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 上的触发器；

转载于:https://www.cnblogs.com/kingwwz/p/5656366.html