有个存储过程A..里面调用了其他存储过程..
有些UPDATE有触发器现在想,怎么样才知道执行存储过程A时,所有涉及到的SQL语句(包括调用的存储过程中的SQL语句)
的锁等待时间和执行时间

解决方案 »

  1.   

    1、看看活动监视器,可以查看锁的信息,执行的语句使用profile进行跟踪
    2、使用dmv
      

  2.   

    用select * from sys.dm_tran_locks 查看一下
      

  3.   

    在系统监测器监视SQL SERVER 中锁活动的情况
    在windows的管理工具中选择性能 单击工具栏上的添加  打开添加计数器 在性能对象组合框中选择SQL SERVER:LOCKS 
      

  4.   


    活动监视器在哪里?profile只显示存储过程的吧?会显示存储过程里面的SQL?
    DMV是啥?
      

  5.   


    sql 20005 select * from sys.dm_os_waiting_tasks 其中wait_duration_ms就是等待时间,不过单看这,还是不够的
      

  6.   


    找到了..活动监视器好像看不出来时哪些SQL啊..最多是进程级别
    DMV是动态管理视图不?用那几个视图?
      

  7.   


    select * from sys.dm_tran_locks  这个好像只是知道当前的所信息吧?
    你这个好像是进程级别的吧?
      

  8.   


    你有没写过?我这个存储过程涉及到销售,全国十几个分公司时时刻刻在用,
    刚开始还没觉得问题,现在运行2年多年..数据光销售订单表就几百万记录了,
    这个存储过程涉及到十几个表,权限啊,属性啊,
    现在执行一次都是10多秒.偶尔还有的可能都执行不了.主要是上班同时用的人多..
    下班之后执行都是一两秒..所有我现在怀疑是并发过多..锁定时间过长,整个存储过程时一个大的事物,
    由于业务逻辑太复杂了..这个存储过程调用的子存储过程,函数,引发的触发器,
    代码至少2千条,还真不好逐个SQL分析

    所以看看怎么才能找出是哪里涉及到长时间的锁
      

  9.   

    现在执行一次都是10多秒.偶尔还有的可能都执行不了.主要是上班同时用的人多.. 
    下班之后执行都是一两秒.. >>>
    首先明确一点,当碰到性能问题时,不能立马就断定是某某方面的问题,需要综合各方面的计数器去下结论.我觉得你首先要收集 memory,cpu,i/o 等几个方面的计数器资料,确定这些没问题後(可以跟下班时间的数据做一个对比),然後再去考虑是不是block方面的问题。SQL Profile 中Errors and wornings 下有个blocked process report事件,你可以观注一下(需要sp_configure配合使用)