zoukankan      html  css  js  c++  java
  • 触发器导致的一个表的死锁问题

    事务(进程 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 时候触发器也是需要等待的;事物隔离

    0VYNZLN2[4UBHI)A8NMJ%]M

    说实话这个触发器,我并不知情的, 然后我把这个禁用掉,问题就解决了;针对business 上的触发器;

  • 相关阅读:
    [Web] 被遗忘的知识点 XHTML
    [项目实践进阶篇] Android 项目中使用Ant + Groovy能干什么?
    使用Ant,第1部分:将Ant脚本引入Java项目
    [Web] 被遗忘的知识点 JavaScript加载管理最佳实践
    [Web] 被遗忘的知识点 iFrames(HTML)过时了没有?
    Android ProGuard
    stream.js
    GUID(全球唯一标识符)
    解析算术表达式
    LCG(linear congruential generator)伪随机数生成器
  • 原文地址:https://www.cnblogs.com/kingwwz/p/5656366.html
Copyright © 2011-2022 走看看