你还应该看一下锁的类似和模式
select 
request_session_id,
OBJECT_NAME( resource_associated_entity_id),
request_mode,request_type
from sys.dm_tran_locks
where resource_type='OBJECT'造成阻塞不是加不加事务的问题,比如你一个更新很慢,如果用不到合理的索引,他就要执行很长时间
此时你其他回话再做查询的话,极有可能被阻塞我觉得你的大表的增删改查要优化一下,看看是不是能合理地用到索引

解决方案 »

  1.   

    想看阻塞的话,用这个alter procedure sp_who_lock
    as
    begin
    declare @spid int,@bl int,
    @intTransactionCountOnEntry int,
    @intRowcount int,
    @intCountProperties int,
    @intCounter int
    create table #tmp_lock_who (
    id int identity(1,1),
    spid smallint,
    bl smallint)
    IF @@ERROR>0 RETURN @@ERROR
    insert into #tmp_lock_who(spid,bl) 
    select 0 as  spid,blocked
    from (select * from sys.sysprocesses where blocked>0 ) a
    where not exists(select * from (select * from sys.sysprocesses
    where blocked>0 ) b
    where a.blocked=spid)
    union select spid,blocked from sys.sysprocesses where blocked>0
    IF @@ERROR>0 RETURN @@ERROR
    -- 找到临时表的记录数
    select @intCountProperties = Count(*),@intCounter = 1
    from #tmp_lock_who
    IF @@ERROR>0 RETURN @@ERROR
    if @intCountProperties=0
    select '现在没有阻塞和死锁信息' as message
    -- 循环开始
    while @intCounter <= @intCountProperties
    begin
    -- 取第一条记录
    select @spid = spid,@bl = bl
    from #tmp_lock_who where Id = @intCounter
    begin
    if @spid =0
    select '引起数据库死锁的是: '+ CAST(@bl AS VARCHAR(10))
    + '进程号,其执行的SQL语法如下'
    else
    select '进程号SPID:'+ CAST(@spid AS VARCHAR(10))+ '被'
    + '进程号SPID:'+ CAST(@bl AS VARCHAR(10)) +'阻塞,其当前进程执行的SQL语法如下'
    DBCC INPUTBUFFER (@bl )
    end
    -- 循环指针下移
    set @intCounter = @intCounter + 1
    end
    drop table #tmp_lock_who
    return 0
    end 
      

  2.   

    还是要分析慢的地方,是因为CPU,IO,还是语句问题产生了错误。来进行定位锁的原因。 根据不同的错误继续深入来查找问题的瓶颈点。 从时间上看,lz这个问题发生在业务高峰时段,可以跟踪一下高峰时段的基本线,看看跟平时的差异。看问题点,可以发生在IO上,如果发生在IO上,注意高发语句的索引使用问题。以及表碎片的问题。