使用V$LOCK解决enq: ST – contention的一个例子
一个用来存储报表的数据库上，有一系列数据导入的进程，但在今天发现这些进程一直未执行结束，在数据导入端可以看到数据导入速度为零，查看数据库上的等待事件，发现它们的等待事件全部是enq: ST – contention（EXTENT分配或者回收的锁）。

SID MACHINE                HASH Event Name                       P1      P2
------ -------------- ------------ -------------------------- -------- ---------
  1069 gateway208063.   2384721791 enq: ST - contention     1398013958        0
   775 gateway208063.   2384721791 enq: ST - contention     1398013958        0

通过查询v$lock这个视图，可以发现某个会话一直占用着ST锁，杀掉这个进程之后，其他的进程的数据导入速度恢复正常。至于这个会话为啥会长久地占用这个锁，没有进一步追查。

SQL> select * from gv$lock where type='ST';
SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---- -- ---------- ---------- ---------- ---------- ---------- ----------
 661 ST          0          0          0          6         73          0
 720 ST          0          0          0          6         73          0
 685 ST          0          0          0          6         72          0
 887 ST          0          0          0          6         72          0
 922 ST          0          0          0          6         72          0
1054 ST          0          0          6          0        261          2
 704 ST          0          0          0          6         75          0
 849 ST          0          0          0          6         75          0
 976 ST          0          0          0          6         75          0
 978 ST          0          0          0          6         75          0
 815 ST          0          0          0          6         75          0

以上是一个非常简单的使用v$lock解决enqueue的问题，但是在解决过程中却花费了我很长的时间，这应该是我没有按照最为直接的思维考虑这个问题导致的。对于这个问题，我们应该这么想：既然等待ST锁，那么ST锁肯定被某个会话占用着，通过V$LOCK查找到这个会话，并审查这个会话的这种行为是否正常。