oracle10g enq:TX - contention等待事件

10g中enqueue TX等待分为4类，分别是
1. enq:TX - row lock contention
2. enq:TX - index contention
3. enq:TX - ITL
4. enq:TX - contention
前三种的含义比较明显，第4种是表示其它类型的transaction contention,即除了前三种之外的都包含在其中。
有多种情况都可能造成enq:TX - contention。比如：一个session中执行DML而不提交，另一个session执行alter tablespace XXX read only,就会出现这个等待事件。

测试情况：
单实例情况：
session 1:
SQL> select sid from v$mystat where rownum <2;

       SID
----------
       145

SQL> select table_name,tablespace_name from user_tables where table_name='INFO';

TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
INFO                           USERS

SQL> update info set note=upper(note);

已更新35行。

SQL> (注意未提交)

session 2:
SQL> select sid from v$mystat where rownum <2;

       SID
----------
       148

SQL> alter tablespace users read only;
由于session 1未提交，还在使用users表空间，session 2出现等待。

session 3:
SQL> select sid,event,p1,p2,p3 from v$session_wait where sid=148;

    SID EVENT                                                                    P1         P2         P3
------- ---------------------------------------------------------------- ---------- ---------- ----------
    148 enq: TX - contention                                             1415053316      65563        166
   
查询得知session 2在等待enq: TX - contention事件。其中p1,p2,p3含义可以从如下视图中得到。

SQL> SELECT name, parameter1, parameter2, parameter3 from v$event_name where name = 'enq: TX - contention';

NAME                      PARAMETER1           PARAMETER2           PARAMETER3
------------------------- -------------------- -------------------- --------------------
enq: TX - contention      name|mode            usn<<16 | slot       sequence

从上述结果中可以看到：
parameter1表示enqueue的name和mode。parameter2的高16位表示事务的xidusn,低16位表示事务的xidslot,parameter3表示事务的xidsqn，即p2,p3表示一个特定的事务。
结合v$transaction和v$session,就可以知道阻塞session 2的会话信息了。

检查enqueue的name和mode
SQL> SELECT sid, CHR (BITAND (p1,-16777216) / 16777215) ||
2         CHR (BITAND (p1, 16711680) / 65535) enq,
3         DECODE (BITAND (p1, 65535), 1, 'Null', 2, 'Sub-Share',
4                  3, 'Sub-Exclusive', 4, 'Share', 5, 'Share/Sub-Exclusive',
5                  6, 'Exclusive', 'Other') lock_mode
6 FROM   v$session_wait WHERE sid = 148;

    SID ENQ LOCK_MODE
------- ---- -------------------
    148 TX   Share

检查阻塞session 2的会话：
SQL> select sid from v$session where taddr in
2 (select b.addr from v$session_wait a,v$transaction b
3 where a.event='enq: TX - contention' and trunc(a.p2/power(2,16)) = xidusn
4 and (bitand(a.p2,to_number('ffff','xxxx'))+0) = xidslot and a.p3 = xidsqn);

    SID
-------
    145
   
这里我们可以看到，造成session 2等待的事务是由session 1执行的。

这里还可以用另一种方法找到阻塞session 2的会话：
1、先查看session 2请求和持有的事务锁情况：
SQL> select sid,id1,id2,trunc(id1/power(2,16)) rbs,bitand(id1,to_number('ffff','xxxx'))+0 slot,id2 seq,lmode,request,type from v$lock where type = 'TX' and sid=&sid;
输入 sid 的值: 148
原值    2: from v$lock where type = 'TX' and sid=&sid
新值    2: from v$lock where type = 'TX' and sid=148

    SID        ID1        ID2        RBS       SLOT        SEQ      LMODE    REQUEST TY
------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- --
    148      65563        166          1         27        166          0          4 TX
    148     196646        168          3         38        168          6          0 TX
148在请求4(share)类型的锁时出现等待。
注意这里的ID1和ID2与v$session_wait中的p2,p3完全一致，都是表示某个事务的。  
SQL> select sid,event,p1,p2,p3 from v$session_wait where sid=148;

    SID EVENT                                                                    P1         P2         P3
------- ---------------------------------------------------------------- ---------- ---------- ----------
    148 enq: TX - contention                                             1415053316      65563        166

2、查看事务(ID1,ID2)使用锁的情况
SQL> select sid,trunc(id1/power(2,16)) rbs,bitand(id1,to_number('ffff','xxxx'))+0 slot,id2 seq,lmode,request
from v$lock where type='TX' and id1=&id1 and id2=&id2;
输入 id1 的值: 65563
输入 id2 的值: 166
原值    2: from v$lock where type='TX' and id1=&id1 and id2=&id2
新值    2: from v$lock where type='TX' and id1=65563 and id2=166

    SID        RBS       SLOT        SEQ      LMODE    REQUEST
------- ---------- ---------- ---------- ---------- ----------
    148          1         27        166          0          4
    145          1         27        166          6          0

这里可以看到148在请求share型事务锁，而145持有exclusive型事务锁，因此造成了session 2的等待。   

RAC情况：与单实例的情况类似
在node 1上执行session：
SQL> conn test/test
Connected.
SQL> select sid from v$mystat where rownum < 2;

       SID
----------
       617
SQL> insert into info values (1);

1 row created.
不提交
      
在node 2上执行session:
SQL> alter tablespace test read only;
出现等待。

在任意node上执行：
SQL> select c.inst_id,c.sid
from gv$session_wait a,gv$transaction b, gv$session c
where a.event='enq: TX - contention'
and trunc(a.p2/power(2,16)) = b.xidusn
and (bitand(a.p2,to_number('ffff','xxxx'))+0) = b.xidslot
and a.p3 = b.xidsqn
and c.taddr = b.addr;

   INST_ID        SID
---------- ----------
         1        617

转载于:https://www.cnblogs.com/rootq/archive/2009/04/17/1438008.html