enq:TM-contention

enq:TM-contention 2011-08-04 15:55:17

分类： Linux

7.1 enq:TM-contention

   

    执行dml期间，为防止对与dml相关的对象进行修改，执行dml的进程必须对该表获得TM锁，若在获得TM锁的过程中发生争用，

 则等待enq:TM-contention事件。

     

    TM锁其用途十分明确，但是准确的概念及定义方面有容易混淆的一面，例如:oracle的concept手册上，关于锁的分类说明如下：

    

    DML锁：data lock，执行dml时保护数据的锁，rowlock (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锁

     争用是否可能引发的问题。

转载 http://blog.itpub.net/7194105/viewspace-704114