none
关于锁的问题 RRS feed

  • 问题

  • 我的情况是有两个表,如果做如下链接

    select *
    from A 
    JOIN B ON A.vno=B.id

    如果运行这个查询的同时有插入A表的操作,那么插入操作就一直在那里运行,要等到查询完成之后才能完成插入。我考虑到是不是是锁的问题,然后我就查了下dm_tran_locks,状态都是lock,A表示S,B表示IS。但是其他的表的关联如果都是S的,那么就可以同时插入的操作。请问为什么会有这种情况?

    2013年4月3日 9:22

答案

  • 插入需要 IX 锁, 这个与 SELECT 的 S 锁是冲突的

    一般考虑在 SELECT 时, 加上 WITH(nolock) 来避免 SELECT 加锁

    2013年4月3日 10:14
  • Keep in mind that nolock hit does dirty read.
    2013年4月3日 13:03
  • http://msdn.microsoft.com/zh-cn/library/bb522682.aspx

    联机查看一下以下设置
    ALLOW_SNAPSHOT_ISOLATION { ON | OFF } READ_COMMITTED_SNAPSHOT {ON | OFF }

    可设置快照隔离,读取其它事务开始的数据,不受其它事务的影响


    Roy Wu(吳熹Blog)(微博)

    2013年4月3日 13:31
    版主
  • --锁资源模式和兼容性
    --SQLSERVER数据库引擎具有多粒度锁定,允许一个事务锁定不同类型的资源。为了尽量
    --减少锁定的开销,数据库引擎自动将资源锁定在适合任务的级别。锁定在较小的粒度
    --(例如:行)可以提高并发度,但开销较高,因为如果锁定了许多行,就需要维护
    --很多锁。锁定在较大的粒度(例如:表),会降低并发度,因为锁定整个表限制了
    --其他事务对表中任务部分的访问,但其开销比较低,因为需要维护的锁数目较小

    --数据库引擎通常必须获取多粒度级别上的锁,才能完整地保护资源。例如,
    --为了完整地保护对某一数据行的读取,SQL实例不但需要获取行上的共享锁
    --还有辅以页和表上的意向共享锁。否则,如果同时有人对这个行所在的页面
    --或表做了改动,也会妨碍事务的正常隔离

    --表 数据库引擎可以锁定的资源
    --资源                               说明
    --RID                        用于锁定堆(heap)中的某一行
    --KEY                        用于锁定索引上的某一行,或者某个索引键
    --PAGE                       锁定数据库中的一个8KB页,例如数据页或索引页
    --EXTENT                     一组连续的8页(区)
    --HOBT                       锁定整个堆或B树的锁
    --TABLE                      锁定包括所有数据和索引的整个表
    --FILE                       数据库文件
    --APPLICATION                应用程序专用的资源
    --METADATA                   元数据锁
    --ALLOCATION_UNIT            分配单元
    --DATABASE                   整个数据库


    --在此基础上,SQL使用不同的锁模式锁定资源,这些锁模式确定了并发事务访问资源
    --的方式

    --表 数据库引擎使用的资源锁模式
    --锁模式                                 说明
    --共享(S)                         用于不更改或不更新数据的读取操作 ,如select语句  在可重复读或可序列化事务中,一个修改需要先读取数据[获取资源(页或行)的共享锁]  
                      
    --更新(U)                         用于可更新的资源中,防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁
    --排他(X)                         用于数据修改操作,例如insert update delete,确保不会同时对一个资源进行多重更新                
    --意向 (I)intent                  用于建立锁的层次结构,意向锁包含三种类型:意向共享(IS)意向排他(IX)意向排他共享(SIX)
    --架构   稳定stable                 在执行依赖于表架构的操作时使用,架构锁包含两种类型:架构修改(sch-m)和架构稳定性(sch-s)
    --大容量更新(BU) bulk insert ,bcp 在向表进行大容量数据复制并且指定了tablock提示时使用
    --键范围                            当使用可序列化事务隔离级别时保护查询读取的行的范围,确保再次运行查询时其他
    --事务无法插入符合可序列化事务的查询的行


    --共享锁:共享锁(S锁)允许并发事务在封闭式并发控制下读取select资源。资源上存在共享锁(S锁)时,任何其他事务都不能修改数据


    --更新锁:在可重复读或可序列化事务中,一个修改需要先读取数据[获取资源(页或行)的共享锁(S锁)],
    --然后修改数据[此操作要求锁转换为排他锁(X锁)。]如果两个事务获得了同一个资源上的共享模式锁,然后试图
    --同时更新数据,则事务会把共享锁转换为排他锁。由于两个事务都要转换为排他锁(X锁),并且每个事务都必须等待
    --另一个事务释放共享锁之后才能得到排他锁,以至于两个事务都无法完成转换,因此发生死锁
    --为了避免这种潜在的死锁问题,SQL使用更新锁(U锁)。一次只有一个事务可以获得资源的更新锁。事务真正修改数据
    --时,将更新锁(U锁)转换为排他锁(X锁)


    --排他锁:排他锁(X锁)可以防止并发事务对资源进行访问。使用排他锁(X锁)时,任何其他事务都无法读取或者修改数据;仅在
    --使用NOLOCK提示或未提交读隔离级别时才会进行读取操作
    --数据修改语句(如insert,update,delete)合并了修改和读取select操作。语句在执行所需的修改操作之前首先执行读取操作以获取数据。
    --因此,数据修改语句通常请求共享锁和排他锁。例如:update语句可能根据与一个表的联接修改另一个表中的行。在此情况下,除了请求
    --更新行上的排他锁之外,update语句还将请求在联接表中读取的行上的共享锁


    --意向锁:数据库引擎使用意向锁来保护锁层次结构的底层资源,以防止其他事务对自己锁住的资源造成伤害,提高锁冲突检测性能
    --例如:当读取表里的页面时,在请求页共享锁(S锁)之前,事务在表级请求共享意向锁。这样可以防止其他事务随后在表上获取
    --排他锁(X锁),修改整个表格。意向锁可以提高性能,因为数据库引擎仅在表级检查意向锁,确定事务是否能安全地获取该表上
    --的锁,而不需要检查表中的每行或每页上的锁以确定事务是否可以锁定整个表


    --架构锁:数据库引擎在表数据定义语言(DDL)操作(例如添加列或删除表)的过程中使用架构修改(sch-m)锁,阻止其他用户
    --对这个表格的访问
    --数据库引擎在编译和执行查询时使用架构稳定(sch-s)锁,稳定stable。sch-s锁不会阻止其他事务访问表格里的数据。但是,
    --会阻止对表格做修改性的DDL操作和DML操作


    --大容量更新锁:数据库引擎在将大容量复制到表中时使用大容量更新(BU)锁,并指定tablelock提示或使用sp_tableoption
    --设置table lock on bulk load表选项。大容量更新锁(BU)锁允许多个线程将数据并发地大容量加载到同一张表,同时
    --防止其他不进行大容量加载数据的进程访问该表 bulk insert ,bcp


    --键范围锁:在使用可序列化(serializable)事务隔离级别时,对于TSQL语句读取的记录集,键范围锁可以隐式包含该记录集中
    --包含的行范围。键范围锁可防止幻读。通过保护行之间键的范围,他还可防止对事务访问的记录集进行幻插入或删除



    ------------------------------------------------锁兼容性----------------------------------------------------------------------
    --锁兼容性控制多个事务能否同时获取同一资源上的锁。如果资源已经被另一事务锁定,则仅当请求锁的模式与现有锁的模式相兼容时,
    --才会授予新的锁请求。如果请求锁的模式与现有锁的模式不兼容,则请求新锁的事务将被迫进入等待状态,阻塞也就随之产生。例如
    --如果一个事务申请了在某个资源上的排他锁(X锁),则在他释放排他锁(X锁)之前,其他事务均无法获取该资源的任何类型(共享,更新,排他)
    --的锁。另一种情况是,如果一个事务已经获得了某个资源上的共享锁(S锁),则即使第一个事务尚未完成,其他事务也可以获取该项的共享锁,
    --更新锁(U锁)。但是,在第一个事务释放共享锁之前,其他事务无法获取排他锁


    --锁模式兼容性:
    --请求模式                     IS          S              U          IX         SIX           X
    --意向共享(IS)针对表,页面   是          是             是         是          是           否
    --共享(S)                    是          是             是         否          否           否
    --更新(U)                    是          是             否         否          否           否
    --意向排他((IX)              是          否             否         是          否           否
    --意向排他共享(SIX)          是          否             否         否          否           否
    --排他(X)                    否          否             否         否          否           否



    --锁的模式和兼容性是SQL预先定义好的,没有任何参数或者配置能够去修改他们。所以要做什么事情,SQL
    --就会去申请什么类型的锁。出现了某种类型的锁,他就会带来预期的兼容性,也就是所谓的事务隔离行为。
    --但是申请锁的粒度,是数据库设计能够影响的。如果应用申请的锁粒度都比较小,产生阻塞的几率就会很小。
    --如果一个连接经常会申请页面级,表级,甚至是数据库一级的锁资源,程序产生阻塞的可能性就会很大

    --应用能够影响隔离的第二个行为,就是一个连接什么时候释放他申请的资源。如果一个连接总是能够非常
    --快地把申请的锁释放掉,那阻塞就不容易发生。如果他总是长时间地持有某些锁资源,那么就很容易发生
    --阻塞了


    --什么行为会影响锁的粒度,以及持有锁的时间长短呢?这个当然和应用定义的事务性质有关系、

    --1、一个事务内部要访问或者修改的数据量越大,他所要申请的锁的数目越多,粒度也就可能越大
    --例如,一个事务如果要修改一张表里面的大部分数据,那在他提交之前,可能其他的用户都无法
    --访问这张表里的记录,而如果这个事务只对一两条记录进行修改,那么大部分用户访问可能不会
    --受到影响


    --2、一个事务做的事情越复杂,他要申请的锁的范围也就越大
    --如果一个事务做的修改只在一个表上,那他只会申请这张表上的锁,访问其他表的用户不会受到影响
    --如果一个事务先后对许多张表做了修改,那访问这些表的用户就都会受到影响


    --3、一个事务延续的时间越长,他持有的锁的时间也会越长
    --很多锁是要在事务提交的时候才会被释放的。如果事务能够很快结束,他申请的锁就不会延续
    --很久,也就不容易阻塞住别人。如果这个事务里有很多句话,或者是某句话要运行很久,或者是
    --语句都结束了,但是连接没有及时提交事务,那有些锁就会一直被这个连接所持有,别人就会很
    --容易被他给阻塞住。

    --上面的因素是比较浅显的,但是和应用逻辑紧密相关。对于一个固定的应用逻辑,这些因素
    --能够调整的余地可能不是很大。为了缓解阻塞问题,还有两大因素影响锁粒度跟持有锁时间
    --:
    --1、事务的隔离级别能影响锁的申请以及释放时间

    --2、语句的执行计划,影响到锁的粒度和申请的数量

    --对于相同的逻辑,如果开发者选择合适的事务隔离级别,引导语句使用优化的执行计划,很多时候
    --也能达到缓解阻塞的目的。

    意向锁的解释数据库引擎使用意向锁来保护锁层次结构的底层资源,以防止其他事务对自己锁住的资源造成伤害,提高锁冲突检测性能
    例如:当读取表里的页面时,在请求页共享锁(S锁)之前,事务在表级请求共享意向锁。这样可以防止其他事务随后在表上获取排他锁(X锁),修改整个表格。意向锁可以提高性能,因为数据库引擎仅在表级检查意向锁,确定事务是否能安全地获取该表上的锁,而不需要检查表中的每行或每页上的锁以确定事务是否可以锁定整个表



    给我写信: QQ我:点击这里给我发消息


    2013年4月7日 12:13

全部回复

  • 两次测试插入与查询是在同一个查询窗口,还是测试插入时打开的新窗口?

    2013年4月3日 10:11
  • 插入需要 IX 锁, 这个与 SELECT 的 S 锁是冲突的

    一般考虑在 SELECT 时, 加上 WITH(nolock) 来避免 SELECT 加锁

    2013年4月3日 10:14
  • Keep in mind that nolock hit does dirty read.
    2013年4月3日 13:03
  • http://msdn.microsoft.com/zh-cn/library/bb522682.aspx

    联机查看一下以下设置
    ALLOW_SNAPSHOT_ISOLATION { ON | OFF } READ_COMMITTED_SNAPSHOT {ON | OFF }

    可设置快照隔离,读取其它事务开始的数据,不受其它事务的影响


    Roy Wu(吳熹Blog)(微博)

    2013年4月3日 13:31
    版主
  • 现在碰到的情况是不知道什么情况select语句会用S锁,什么情况会用IS锁。我实验下来的没有找到规律。只是碰到一个情况是先select,那么会用到S锁,之后insert是IX锁所以会有冲突。顺序反过来的话就变成先由于insert是IX锁,select后本来的S锁会变成IS锁,感觉是降级了。到底select什么时候是IS什么时候是S完全找不到规律啊。



    • 已编辑 dna_xp 2013年4月7日 4:21
    2013年4月7日 4:06
  • I:意向共享锁  当要查询的数据较多的时候,sql会加这个锁 锁住整个表

    LZ可以看一下这篇文章

    意向锁如何提高性能


    给我写信: QQ我:点击这里给我发消息

    2013年4月7日 12:12
  • --锁资源模式和兼容性
    --SQLSERVER数据库引擎具有多粒度锁定,允许一个事务锁定不同类型的资源。为了尽量
    --减少锁定的开销,数据库引擎自动将资源锁定在适合任务的级别。锁定在较小的粒度
    --(例如:行)可以提高并发度,但开销较高,因为如果锁定了许多行,就需要维护
    --很多锁。锁定在较大的粒度(例如:表),会降低并发度,因为锁定整个表限制了
    --其他事务对表中任务部分的访问,但其开销比较低,因为需要维护的锁数目较小

    --数据库引擎通常必须获取多粒度级别上的锁,才能完整地保护资源。例如,
    --为了完整地保护对某一数据行的读取,SQL实例不但需要获取行上的共享锁
    --还有辅以页和表上的意向共享锁。否则,如果同时有人对这个行所在的页面
    --或表做了改动,也会妨碍事务的正常隔离

    --表 数据库引擎可以锁定的资源
    --资源                               说明
    --RID                        用于锁定堆(heap)中的某一行
    --KEY                        用于锁定索引上的某一行,或者某个索引键
    --PAGE                       锁定数据库中的一个8KB页,例如数据页或索引页
    --EXTENT                     一组连续的8页(区)
    --HOBT                       锁定整个堆或B树的锁
    --TABLE                      锁定包括所有数据和索引的整个表
    --FILE                       数据库文件
    --APPLICATION                应用程序专用的资源
    --METADATA                   元数据锁
    --ALLOCATION_UNIT            分配单元
    --DATABASE                   整个数据库


    --在此基础上,SQL使用不同的锁模式锁定资源,这些锁模式确定了并发事务访问资源
    --的方式

    --表 数据库引擎使用的资源锁模式
    --锁模式                                 说明
    --共享(S)                         用于不更改或不更新数据的读取操作 ,如select语句  在可重复读或可序列化事务中,一个修改需要先读取数据[获取资源(页或行)的共享锁]  
                      
    --更新(U)                         用于可更新的资源中,防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁
    --排他(X)                         用于数据修改操作,例如insert update delete,确保不会同时对一个资源进行多重更新                
    --意向 (I)intent                  用于建立锁的层次结构,意向锁包含三种类型:意向共享(IS)意向排他(IX)意向排他共享(SIX)
    --架构   稳定stable                 在执行依赖于表架构的操作时使用,架构锁包含两种类型:架构修改(sch-m)和架构稳定性(sch-s)
    --大容量更新(BU) bulk insert ,bcp 在向表进行大容量数据复制并且指定了tablock提示时使用
    --键范围                            当使用可序列化事务隔离级别时保护查询读取的行的范围,确保再次运行查询时其他
    --事务无法插入符合可序列化事务的查询的行


    --共享锁:共享锁(S锁)允许并发事务在封闭式并发控制下读取select资源。资源上存在共享锁(S锁)时,任何其他事务都不能修改数据


    --更新锁:在可重复读或可序列化事务中,一个修改需要先读取数据[获取资源(页或行)的共享锁(S锁)],
    --然后修改数据[此操作要求锁转换为排他锁(X锁)。]如果两个事务获得了同一个资源上的共享模式锁,然后试图
    --同时更新数据,则事务会把共享锁转换为排他锁。由于两个事务都要转换为排他锁(X锁),并且每个事务都必须等待
    --另一个事务释放共享锁之后才能得到排他锁,以至于两个事务都无法完成转换,因此发生死锁
    --为了避免这种潜在的死锁问题,SQL使用更新锁(U锁)。一次只有一个事务可以获得资源的更新锁。事务真正修改数据
    --时,将更新锁(U锁)转换为排他锁(X锁)


    --排他锁:排他锁(X锁)可以防止并发事务对资源进行访问。使用排他锁(X锁)时,任何其他事务都无法读取或者修改数据;仅在
    --使用NOLOCK提示或未提交读隔离级别时才会进行读取操作
    --数据修改语句(如insert,update,delete)合并了修改和读取select操作。语句在执行所需的修改操作之前首先执行读取操作以获取数据。
    --因此,数据修改语句通常请求共享锁和排他锁。例如:update语句可能根据与一个表的联接修改另一个表中的行。在此情况下,除了请求
    --更新行上的排他锁之外,update语句还将请求在联接表中读取的行上的共享锁


    --意向锁:数据库引擎使用意向锁来保护锁层次结构的底层资源,以防止其他事务对自己锁住的资源造成伤害,提高锁冲突检测性能
    --例如:当读取表里的页面时,在请求页共享锁(S锁)之前,事务在表级请求共享意向锁。这样可以防止其他事务随后在表上获取
    --排他锁(X锁),修改整个表格。意向锁可以提高性能,因为数据库引擎仅在表级检查意向锁,确定事务是否能安全地获取该表上
    --的锁,而不需要检查表中的每行或每页上的锁以确定事务是否可以锁定整个表


    --架构锁:数据库引擎在表数据定义语言(DDL)操作(例如添加列或删除表)的过程中使用架构修改(sch-m)锁,阻止其他用户
    --对这个表格的访问
    --数据库引擎在编译和执行查询时使用架构稳定(sch-s)锁,稳定stable。sch-s锁不会阻止其他事务访问表格里的数据。但是,
    --会阻止对表格做修改性的DDL操作和DML操作


    --大容量更新锁:数据库引擎在将大容量复制到表中时使用大容量更新(BU)锁,并指定tablelock提示或使用sp_tableoption
    --设置table lock on bulk load表选项。大容量更新锁(BU)锁允许多个线程将数据并发地大容量加载到同一张表,同时
    --防止其他不进行大容量加载数据的进程访问该表 bulk insert ,bcp


    --键范围锁:在使用可序列化(serializable)事务隔离级别时,对于TSQL语句读取的记录集,键范围锁可以隐式包含该记录集中
    --包含的行范围。键范围锁可防止幻读。通过保护行之间键的范围,他还可防止对事务访问的记录集进行幻插入或删除



    ------------------------------------------------锁兼容性----------------------------------------------------------------------
    --锁兼容性控制多个事务能否同时获取同一资源上的锁。如果资源已经被另一事务锁定,则仅当请求锁的模式与现有锁的模式相兼容时,
    --才会授予新的锁请求。如果请求锁的模式与现有锁的模式不兼容,则请求新锁的事务将被迫进入等待状态,阻塞也就随之产生。例如
    --如果一个事务申请了在某个资源上的排他锁(X锁),则在他释放排他锁(X锁)之前,其他事务均无法获取该资源的任何类型(共享,更新,排他)
    --的锁。另一种情况是,如果一个事务已经获得了某个资源上的共享锁(S锁),则即使第一个事务尚未完成,其他事务也可以获取该项的共享锁,
    --更新锁(U锁)。但是,在第一个事务释放共享锁之前,其他事务无法获取排他锁


    --锁模式兼容性:
    --请求模式                     IS          S              U          IX         SIX           X
    --意向共享(IS)针对表,页面   是          是             是         是          是           否
    --共享(S)                    是          是             是         否          否           否
    --更新(U)                    是          是             否         否          否           否
    --意向排他((IX)              是          否             否         是          否           否
    --意向排他共享(SIX)          是          否             否         否          否           否
    --排他(X)                    否          否             否         否          否           否



    --锁的模式和兼容性是SQL预先定义好的,没有任何参数或者配置能够去修改他们。所以要做什么事情,SQL
    --就会去申请什么类型的锁。出现了某种类型的锁,他就会带来预期的兼容性,也就是所谓的事务隔离行为。
    --但是申请锁的粒度,是数据库设计能够影响的。如果应用申请的锁粒度都比较小,产生阻塞的几率就会很小。
    --如果一个连接经常会申请页面级,表级,甚至是数据库一级的锁资源,程序产生阻塞的可能性就会很大

    --应用能够影响隔离的第二个行为,就是一个连接什么时候释放他申请的资源。如果一个连接总是能够非常
    --快地把申请的锁释放掉,那阻塞就不容易发生。如果他总是长时间地持有某些锁资源,那么就很容易发生
    --阻塞了


    --什么行为会影响锁的粒度,以及持有锁的时间长短呢?这个当然和应用定义的事务性质有关系、

    --1、一个事务内部要访问或者修改的数据量越大,他所要申请的锁的数目越多,粒度也就可能越大
    --例如,一个事务如果要修改一张表里面的大部分数据,那在他提交之前,可能其他的用户都无法
    --访问这张表里的记录,而如果这个事务只对一两条记录进行修改,那么大部分用户访问可能不会
    --受到影响


    --2、一个事务做的事情越复杂,他要申请的锁的范围也就越大
    --如果一个事务做的修改只在一个表上,那他只会申请这张表上的锁,访问其他表的用户不会受到影响
    --如果一个事务先后对许多张表做了修改,那访问这些表的用户就都会受到影响


    --3、一个事务延续的时间越长,他持有的锁的时间也会越长
    --很多锁是要在事务提交的时候才会被释放的。如果事务能够很快结束,他申请的锁就不会延续
    --很久,也就不容易阻塞住别人。如果这个事务里有很多句话,或者是某句话要运行很久,或者是
    --语句都结束了,但是连接没有及时提交事务,那有些锁就会一直被这个连接所持有,别人就会很
    --容易被他给阻塞住。

    --上面的因素是比较浅显的,但是和应用逻辑紧密相关。对于一个固定的应用逻辑,这些因素
    --能够调整的余地可能不是很大。为了缓解阻塞问题,还有两大因素影响锁粒度跟持有锁时间
    --:
    --1、事务的隔离级别能影响锁的申请以及释放时间

    --2、语句的执行计划,影响到锁的粒度和申请的数量

    --对于相同的逻辑,如果开发者选择合适的事务隔离级别,引导语句使用优化的执行计划,很多时候
    --也能达到缓解阻塞的目的。

    意向锁的解释数据库引擎使用意向锁来保护锁层次结构的底层资源,以防止其他事务对自己锁住的资源造成伤害,提高锁冲突检测性能
    例如:当读取表里的页面时,在请求页共享锁(S锁)之前,事务在表级请求共享意向锁。这样可以防止其他事务随后在表上获取排他锁(X锁),修改整个表格。意向锁可以提高性能,因为数据库引擎仅在表级检查意向锁,确定事务是否能安全地获取该表上的锁,而不需要检查表中的每行或每页上的锁以确定事务是否可以锁定整个表



    给我写信: QQ我:点击这里给我发消息


    2013年4月7日 12:13
  • --如何监视锁的申请,持有和释放 锁的数量和数据库调优的关系

    --在分析不同形式的语句执行对申请锁行为的影响之前,DBA要先了解怎麽去监视
    --一个连接当前持有的锁,以及怎麽去监视一个语句的执行过程,SQLSERVER对锁
    --的申请和释放行为

    --1、检查一个连接当前所持有的锁
    --通常可以使用sp_lock这个命令来列出当前SQL里所有的连接所持有的锁的内容要授予先可以获得锁
    EXEC [sys].[sp_lock]


    --在SQL2005之后,这个功能可以由直接查询sys.dm_tran_locks这张系统动态管理视图来实现
    SELECT [request_session_id],
    [resource_type],
    [resource_associated_entity_id],
    [request_type],
    [request_mode],
    [resource_description]
    FROM sys.[dm_tran_locks]


    --当然也可以结合其他动态管理视图,直接查出某个数据库上面的锁是在哪些表格,以及哪些索引上面
    --例如:
    USE [GPOSDB]  --要查询锁的数据库
    GO
    SELECT
    [request_session_id],
    [resource_type],
    [resource_associated_entity_id],
    [request_status],
    [request_mode],
    [resource_description],
    p.[object_id],
    OBJECT_NAME(p.[object_id]) AS objectname,
    p.*
    FROM sys.[dm_tran_locks] LEFT JOIN sys.[partitions] p ON sys.[dm_tran_locks].[resource_associated_entity_id]
    =p.[hobt_id]
    WHERE [resource_database_id]=DB_ID('gposdb')
    ORDER BY [request_session_id],[resource_type],[resource_associated_entity_id]



    --2、监视语句执行过程中SQL对锁的申请和释放行为
    --有很多锁是在语句运行的过程中申请和释放的,语句运行结束之后,这些锁就会消失。
    --如果这些锁申请不到,也会产生阻塞。那么怎麽看一个语句执行过程中锁的申请和释放过程呢?

    --DBA必须借助SQLSERVER PROFILER 在定义一个trace(跟踪)的时候,需要选取下面的event(事件)
    --:lock:accquired,lock:released 选上show all columns显示所有列和显示所有事件
    --选上show all columns显示所有列和显示所有事件

    给我写信: QQ我:点击这里给我发消息


    2013年4月7日 12:17