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$