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锁
争用是否可能引发的问题。