ITPub博客

首页 > 数据库 > Oracle > enq:TM-contention说明

enq:TM-contention说明

Oracle 作者:Curry_0316 时间:2016-02-17 17:28:12 0 删除 编辑
文章转自:
http://blog.itpub.net/7194105/viewspace-704114/

    执行dml期间,为防止对与dml相关的对象进行修改,执行dml的进程必须对该表获得TM锁,若在获得TM锁的过程中发生争用,则等待enq:TM-contention事件。
     
    TM锁其用途十分明确,但是准确的概念及定义方面有容易混淆的一面,例如:oracle的concept手册上,关于锁的分类说明如下:
    
    DML锁:data lock,执行dml时保护数据的锁,row lock(tx)保护特定的行,table lock(tm)保护整个表,可以通过DBA_DML_LOCKS 观察
    
    DDL锁:data dictionary lock,保护user/table/view/procedure等定义,可以通过dba_ddl_locks观察。
    
    internal locks and latches.
    
    以上说明可能让大家以为存在DML锁和DDL锁这两个锁,给大家带来混乱,实际上,DML和DDL锁只是为了合理分配锁而赋予的名称,请注意这一点
    
    DML锁实际上与TM锁一致,DML锁可以通过DBA_DML_LOCKS视图观察,这个视图的作用是从V$LOCK视图上筛选类型的TM的,数据库上运行的TM锁数量可以利用DML_LOCKS参数知道,若DML_LOCKS这个参数设为0,则对于表无法获得TM锁,这时,oracle为了保障表定义保护,对于表根本上不运行执行DDL操作因此,即便不获得TM锁,也运行修改表的特定行,如OPS环境下,为了减少在群集范围内获得TM锁中发生的附加资源消耗,有时也将DML_LOCKS值修改为0.
    
    DDL锁实际上和Library cache lock一致,DDL锁可以通过DBA_DDL_LOCKS视图观察,这个视图实际上起到加工X$KGLLK视图后显示的作用。DDL锁除DBA_DDL_LOCKS视图以外,还可以通过X$KGLLK,DBA_KGLLOCK等视图观察。
    
    对于表,普通DML语句以SUB-Exclusive(SX-意向排他锁)获得TM锁,SUB-exclusive模式之间存在共享性,所以多个会话可以对相同的表执行DML已执行DML的会话对于表,以sub-exclusive模式获得TM锁,对于已修改的数据以EXCLUSIIVE模式获得TX锁。
    
    所以如下所示,可以通过V$LOCK视图,可以观察执行DML的会话以何种模式获得了哪些锁。
    
    enq:TM-contention等待的发生,发生TM锁争用的情况如下:
    
    1、修改无索引外键(foreign key)的父键时
    2、DML与DDL之间的TM争用
    3、LOCK TABLE 引起的TM锁争用
    4、direct load工作引起的TM锁争用
    
   7.1.1、无索引的外键
    
    oralce 9i之前,没有索引的外键列是TM锁争用的主要原因,oracle 9i之前的版本,子表的外键列没有索引的状态下,若父表的KEY被修改,则对子表以shared模式或shared -sub-exclusive模式获得TM锁。已获得TM锁一直拥有直到父表修改key的事务结束为止(commit或rollback),因此经常发生严重的性能下降的现象,但是从oracle 9i开始,算法大幅改善,不再发生类似的争用现象,若还是使用oracle9i之前的版本,则需要养成在外键列上创建索引的习惯。
   
   7.1.2 不当的DDL引起的TM争用
   
   对于事务正在运行的表,基本上不可能执行DDL,因此,这时不会发生争用引起的性能问题。
   
   减少DDL引起的TM锁争用的方法如下:
   
   1、若对于数据多的表执行不当的DDL,则访问此表的所有DDL都会陷入等待状态,可能发展至故障状态,通过合理的管理,从根本上防止才是最好的方法。
   2、执行DDL时,最好使用ONLINE选项,随着oracle版本升级,online状态下可执行的DDL逐步增加,大部分普通DDL上,可以使用ONLINE选项,例如
    online选项执行create index命令,不是以shared模式,而是以sub-shared(ss)(意向共享锁)模式获得TM锁的这句话的解释是:
    创建索引的时候获取的TM锁的模式是SS模式(sub-shared)  v$lock中lmod 是2;
    对表做DML获取的TM锁的模式是SX(Sub-exclusive)  v$lock 中lmod是4;
    两种模式sub-shared 和 sub-exclusive 可以共享性。
   
   所以在创建索引的过程中,可以执行DML,即,不会发生enq:TM-contention等待。
   
   3、使用并行parallel DDL将DDL的执行速率最大化,对拥有大量数据的表执行DDL时,若恰当使用Parallel选项,可将DDL本事性能最大化,而且同时使用nologging选项比较好,如果提升了DDL执行速度,TX锁争用引起的等待时间相应地也会下降。
 
    
   7.1.3 利用lock table 主动获取TM锁
   
   利用lock table...语句有意获取TM锁时,可能发生TM锁争用。
   
   会话1 update test set id1=where rownum=1;
   会话2 lock table test in exclusive mode;
   
   如上所示,会话1 上因update以sub-exclusive模式获得TM锁的状态下,会话2利用lock table命令试图以exclusive模式获得TM锁,如果发生争用,则等待enq:TM-contention事件。
   
   发生TM锁引起的争用时,收集锁拥有者(lock holder),在会话上执行的sql语句尤为重要,发生TM锁的情况非常多样,因此没有SQL语句,就很难做出准确判断的情况较多,引发问题的SQL语句是LOCK table语句,因此如果发生大量的TM锁争用,可以通过对应用程序的适当修正解决争用。
   与其为了同步整个表上锁,不如考虑使用dbms_lock成包或使用select for update等,减少范围的方法。
    
    select .. for update 对整个TM锁使用sub exclusive 模式,对TX锁使用记录行上的exclusive.
    lock table test in exclusive mode;对整个表TM锁获取exclusive模式。
    
    
     7.1.4 执行direct/parallel load工作时这一点很容易被人忽略
     
     insert /*+*append/ into或sql*loader的direct path load之类的部分功能,对于相应表以exclusive模式获得tm锁,direct load工作不经过sga,而是直接写入到数据文件里,所以在执行工作期间不运行对表进行任何修改。得到保障,工作才能得以继续。
     
     direct load工作在执行期间,不运行对于表执行任何DDL或DML.因此事务多的时刻执行direct load工作时,需要确认TM锁争用是否可能引发的问题。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29953799/viewspace-1990134/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2014-10-11

  • 博文量
    86
  • 访问量
    245684