enqueue：HW问题分析与解决

最新推荐文章于 2022-12-29 21:35:59 发布

iteye_4537

最新推荐文章于 2022-12-29 21:35:59 发布

阅读量194

点赞数

文章标签：数据库

本文讨论了一个Oracle9.2.0.8+HP-UX11.31系统在月底繁忙时段出现的EnqueueHW等待问题，主要原因是并发操作导致的数据块争用。通过分析SQL执行、锁模式、数据块位置等信息，最终定位到问题源于特定对象的高并发插入操作。解决办法包括预分配空间、使用ASSM（Automatic Segment Space Management）等措施，以避免后续的Enqueue等待。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

平台：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