在RDBMS系统中，发生enqueue等待特别是enqueue TX-contention是再正常不过的了，原因很简单，为了满足ACID原则。但如果是enqueue HW-contention,你遇到的机会就要稍微少一些了，因为这一般只发生在大量数据装载或者是OLTP业务非常繁忙的系统中。

这不，我们的一个银行用好，恰巧就发生了这么一个问题，当大批量数据装载时，系统CPU使用率接近100%（这可是128CPU的HP superdome），而这其中的90%以上，是在等待enqueue HW 。当然，这个系统的架构有其特殊性，每个表只有两个字段，一个number，一个LOB（这个时候，你可能就会发现架构师对性能的影响有多么巨大了）。

HW=HighWatermark，所谓的高水位竞争。就是当数据插入的session过多，对最后一个可用块的竞争，以得到下一个空闲块（或者extent)。

这种情况，如果是普通表，使用alter table <TABNAME> allocate extent 提前多分配extent即可解决。

但是含有LOB（clob）字段的表，据客户反应，用这个方法在loading装载开始后的2分钟之内是有效的，但之后就不灵了，原因和在？ 原因处在lob方式。

解决方式分两种，在ASSM表空间之内的：

 a) As temporary workaround, manually add extra space to the LOB segment
      ALTER TABLE <lob_table>
      MODIFY LOB (<column_name>) (allocate extent (size <extent size>));
OR
   b) It may related Bug 6376915. 
   Refer to Note 6376915.8 “Bug 6376915 HW enqueue contention for ASSM LOB segments”
   In 10.2.0.4 or above, this fix has been included, and can be enabled by setting event 44951 to a value
   between 1 and 1024.  A higher value would be more beneficial in reducing contention.
   EVENT=”44951 TRACE NAME CONTEXT FOREVER, LEVEL < 1 – 1024 >”
OR
  c) Consider partitioning the LOB  in a manner that will evenly distribute concurrent DML across multiple 
      partitions  

使用MSSM的：

a) As temporary workaround, manually add extra space to the LOB segment
    ALTER TABLE <lob_table>    
    MODIFY LOB (<column_name>) (allocate extent (size <extent size>));
OR
     b) Consider partitioning the LOB in a manner that will evenly distribute concurrent DML across multiple
      partitions

 如我先去提到的，由于表的字段只有两个，lob字段中包含的内容实在太复杂，所以partition方式无法处理这个问题。只能是每次装载前，使用批处理的方式，预先分配200G左右的lob extent。