enqueue：HW问题分析与解决

 平台：oracle 9.2.0.8 + hpux 11.31
 现象描述：月底系统繁忙，问题频出，这个和上篇不是同一个系统。100多个enqueue等待事件，平日运行稳定是应该一个都没有
 
  SID    SERIAL# OSUSER   USERNAME SVRPROC      PROCESS      EVENT                                             P1         P2         P3
------ ---------- -------- -------- ------------ ------------ ------------------------------ --------------------- ---------- ----------
  3893      65320 sadmin   LDAPUSER  3150         21304:27520  enqueue                                   1213661190         14 3233832969
  4030      32072 sadmin   LDAPUSER 19910        32792:26336  enqueue                                   1213661190         14 3233832969
.....

根据p1快速定位到类型为HW mode6，在通过p2,p3可以定位到具体的数据块和对象，这里的p2,p3和v$lock中的ID1，ID2的值相同

SQL> @enqueue.sql

   SID Lock     Mode
------ -------- ----------------------------------------
    52 HW       6
    75 HW       6
    
SQL> SELECT chr(to_char(bitand(1213661190,-16777216))/16777215)||
  2   chr(to_char(bitand(1213661190, 16711680))/65535) "Lock",
  3   to_char( bitand(1213661190, 65535) )    "Mode" from dual;

Lo M
-- -
HW 6

根据p2定位的数据块
SQL> select DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(3233832969) FILE#,
  2  DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(3233832969) BLOCK#
  3  from dual;

     FILE#     BLOCK#
---------- ----------
       771      24585

 定位到具体的对象      

SQL> select owner, segment_type, segment_name
  2      from dba_extents
  3      where file_id = 771
  4      and 24585 between block_id and block_id + blocks -1;

OWNER                          SEGMENT_TYPE       SEGMENT_NAME
------------------------------ ------------------ ----------------------------------------------------------------------------------------------------
SIEBEL                         TABLE              CX_LOG3

从statspack已可以看到，top sql都是关于此对象的sql，也验证了前面的判断。

SQL> set linesize 200;
SQL> /

        HV SQL_TEXT                        BUFFER_GETS EXECUTIONS ELAPSED_TIME_HOUR CPU_TIME_S DISK_READS AVG_TIME_S   AVG_ROWS
---------- ------------------------------- ----------- ---------- ----------------- ---------- ---------- ---------- ----------
2196997211   INSERT INTO SIEBEL.CX_LOG3  (    15247165     550447             19.29     412.25       1480       .126          1
3813933981   INSERT INTO SIEBEL.CX_LOG3  (    13642539     474684             17.98     360.93      46049       .136          1
2105053489   INSERT INTO SIEBEL.CX_LOG3  (     7461687     264451             11.35        222       2157       .155          1
4155853741   INSERT INTO SIEBEL.CX_LOG3  (     7971754     241499              7.84     178.65       2315       .117          1
4019360030 SELECT       T2.CONFLICT_ID,     -3.791E+09       4288              7.11   18327.24     157042      5.969         .7



为什么会有Enqueue HW等待呢？metalink中HW多出现在并发对表大量进行DML操作时，当表含有Lob字段时，争用会更加严重。该表虽无lob，但有VARCHAR2(2000 CHAR)的长字符字段，估计效果相当于lob。

解决办法：
由于历史原因，该表空间是Manual Segment Space Management(MSSM)管理方式，当分配新的extent时，会导致enqueue HW
解决办法比较可行的看样子只能是alter table <TABNAME> allocate extent，提前分配空间了。不知道增加extent的大小，一次分配更大的extent能够解决问题.当然最好的办法还是使用ASSM。
 alter table CX_LOG5 allocate extent ( size 1000M);
 资料中解决此类问题的方法还有：
HW enqueue The HW enqueue is used to serialize the allocation of space beyond the high water mark of a segment.
If this is a point of contention for an object, then manual allocation of extents solves the problem.
Use Freelists：Cause multiple jumps in High Water Mark
Pre-Allocate Extents：Alter table XXXX allocate extent;
Hidden Parameter：bump_highwater_mark_count
ASSM：Automatic segment space management