合 ASSM引发的索引争用与 enq HW - contention 等待事件
故障概述
2017年07月24日11:58左右，客户核心数据库出现大量活动会话，导致数据库负载急剧加大，从而导致业务出现延时，DBA通过查看SESSION信息发现有大量的“enq: HW - contention”等待事件。
一直持续约有3分钟，数据库负载下降：
下面是详细的故障分析诊断过程，以及详细的解决方案描述。
故障现象
ENMODB数据库出现大量活动会话，数据库负载急剧加大，通过V$SESSION能看到大量enq：HW contention的活动会话信息，客户紧急采集了ASH信息，方便后期故障分析。
分析过程
从AWR和ASH两个维度来分析此故障，先整体后局部，首先从AWR分析入手。
1、AWR分析
首先看一下故障时间段的AWR报告：
半小时的采样时间，DB Time 215mins，其中等待时间“enq: HW - contention”占据近36%，为TOP 10 events中最主要的非空闲等待事件。
等待事件“enq: HW - contention”的解释：
The HW enqueue is used to manage the allocation of space beyond the high water mark of a segment. The high water mark of a segment is the boundary between used and unused space in that segment. If contention is occurring for "enq: HW - contention" it is possible that automatic extension is occuring to allow the extra data to be stored since the High Water Mark has been reached. Frequent allocation of extents,reclaiming chunks,and sometimes poor I/O performance may be causing contention for the LOB segments high water mark.
The HW enqueue is used to serialize the allocation of space beyond the high water mark of a segment. If lots of data is being added to an object concurrently, then multiple processes may be trying to allocate space above the high water mark at the same time, leading to contention.
简而言之，HW锁是在分配高水位线以上的空闲空间时，多个进程同时为了分配高水位线上空闲空间而修改HWM，修改HWM需要持有HW锁，该锁又属于排他锁（mode=6）。
如果大量数据被并发插入某个对象时，那多个进程可能会试图在高水位线以上同时申请可用空间，大并发的申请HW锁，从而导致HW enqueue争用。HW – contention等待事件的P1，P2，P3参数参考下表；
| Event | P1 Parameter | P2 Parameter | Parameter 3 |
|---|---|---|---|
| enq: HW - contention | name|mode | table space | # block |
发现这个时间段确实有大量的INSERT操作，半小时采用中，该SQL执行了约近24w次。
下一步看看HW竞争是在表段还是在索引段上？
大量的物理读/物理写请求也都发生在表TAB_ENMO的索引上。这里可以猜测HW竞争可能不在表上，而在这几个索引上面，IO读写请求非常高。
2、ASH分析
通过客户采集的ASH分析发现，等待事件“enq: HW - contention”是从07月24日11:57:12秒左右开始的，此类session全部被session id为1191的会话阻塞。
查看1191会话信息，发现11:57:12的时候没有被任何会话阻塞（NOT IN WAIT），Session状态是ON CPU：
这个时间点11:57:12的时候会话1191在执行以下的INSERT操作，这个就是源头，并且这个SQL一直在执行。
INSERT操作从11:57:11开始，后续该会话一直都是HW竞争，并且跟其他SESSION争相持有HW锁。
这个时间点大量的SESSION都在持续申请HW锁，因此都在相互blocking sessions。从p1，p2，p3参数中发现P3值并不代表争用块的RDBA（data block address）（36730这个值太小了，这是为啥？先思考下）。
既然P3找不到RDBA，那就从ash中字段CURRENT_FILE#和CURRENT_BLOCK#上寻找争用块：
发现所有的HW竞争都发生在索引IDX_TAB_ENMO_SEQ上，该索引就是表TAB_ENMO上的索引，HW竞争的SQL语句也是上面AWR中发现的SQL。
既然是大并发持有HW锁，多个进程是持续不断的申请HW锁，说明不断的发现free space不足，一般ASSM管理都是一次性分配多个extent，根据对象大小一个extent下面又会有多个block。除非指定storage参数next size 大小：
表空间ENMO_DATA是ASSM（自动段空间管理），并且是本地管理表空间，获取表空间的定义语句：
表空间自动扩展NEXT SIZE 100M。段管理方式使用自动段空间管理（ASSM）。这里有个地方值得关注下，这个表空间属于bigfile tablespace，这就是为什么通过等待事件中的p1，p2，p3参数无法精确定位到具体发生争用的block了。
