[zt] 處理LOB(大物件)表enqueue HW問題的一個方法

 

在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  allocate extent 提前多分配extent即可解決。

但是含有LOB（clob）欄位的表，據客戶反應，用這個方法在loading裝載開始後的2分鐘之內是有效的，但之後就不靈了，原因和在？ 原因處在lob方式。

解決方式分兩種，在ASSM表空間之內的：

 a) As temporary workaround, manually add extra space to the LOB segment
      ALTER TABLE
      MODIFY LOB () (allocate extent (size ));
OR
   b) It may related . 
   Refer to “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     
    MODIFY LOB () (allocate 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。