HW真的是个著名的enqueue lock，著名度仅次于TM、TX吧。对于有高并发INSERT的OLTP数据库的DBA而言，HW enqueue真实家常便饭的等待事件。但是对于该等待事件的详细说明却少之又少。 这里我们总结一下这个HW enqueue lock。
这里我们仅讨论high water mark高水位队列锁的相关信息以及其常见使用和争用场景。
虽然造成HW enqueue contention争用的根本原因多种多样，但本质上HW enqueue总是只在数据段segment的High Water Mark高水位线需要移动时才被持有，最常见的情形莫过于一顿并发猛烈地INSERT操作。
HW enqueue根本存在目的是为了串行化对segment高水位线的移动以及回收lob segment中的空间。 已删除的LOB CHUNK在LOB INDEX中得到维护，以达到一致性读的目的；当LOB SEGMENT中的free space即将耗尽时则会则会从LOB INDEX中回收已提交的空闲空间。在持有HW enqueue的情况下Oracle操作从LOB INDEX移动free space到LOB本身SEGMENT的操作。
对于HW enq往往能采取以下的措施
1. 在segment扩展时，_bump_highwater_mark_count隐藏参数指出了单次高水位上涨的块数，但是该隐藏参数将影响整个DB。
2. 通过ATLER TABLE allocate extent (instance X)为指定实例、指定表预分配extent是另一种备选的解决HW enqueue的方案，而且该方案较为安全
3. 也建议检查表上的freelist 、fresslist group设置，若设置得过高，则可能由于格式化所有移动到freelist中的数据块而导致segment hw持有很长一段时间
4. 若在lob space回收期间发生该HW enq问题，则考虑检查LOB的pctversion配置。基于实际使用情况你可以设置pctversion为0或更小之避免空间回收，默认值为10%
不管是LMT本地管理还是DMT字典管理表空间总是要求在扩展数据段segment时持有HW enqueue。虽然在LMT上这种持有周期更短，但这仍是一个串行化的扩展过程。
如何避免争用：
以下是2中避免HW enq争用的行之有效方案：
1. 重建该对象并配以freelist group、并为每个实例预分配EXTENT，语法为 ALTER TABLE..allocate extent(INSTANCE X)。这种措施有效改善性能，但也可能造成某个实例释放的数据块不能为其他实例所用的确定。 一般来说若实例间的删除DELETES和UPDATES更新是平衡的，则实际不构成问题。
2.若这种预分配仍不够显效，则考虑增加free list的数目。高水位线移动的速度很大取决于free list数目。
Enq HW的ID1、ID2
id1为扩展数据段(具体指高水位要调整的数据段)所在的表空间号tablespace number， ID2为segment header段头的RDBA 相对数据块地址。
相关的一些BUG号：
1. Bug 4113930 documents a problem where MSSM LOBS may see a performance problem with this
enqueue.
2. Bug 4867884 reports that HW contention can be seen with LOB space reclamation.
3. Bug 6376915 introduces event 44951 to reduce HW contention for ASSM managed LOB segments.
PS:
空间管理层如此 使用HW high water mark 队列锁：
如同边界线一般保护段的高水位上升， 在高水位一下的segment header或bitmap block总是在RAC中被传来用去，同样的会需要格式化新的块来提供新的空间以便插入
hw enqueue lock会一直被持有直到新块被格式化完，这些新块一般被以排他模式pin，这造成RAC通信以同步GCS。
HW enqueue长伴随有高频率的global cache open x(9i)和gc current grant 2-way(10g)
一般来说，频繁的格式化新块和高水位移动会造成INSERT的响应时间变长也会造成更多的CPU消耗。
因此考虑如下优化数据结构减少争用：
1. 考虑用更大size的block，这样做的好处是减少了需要格式化新块的需求量，坏处是若更新比INSERT频繁那么可能造成其他争用
2. 使用free list group和预分配的extent(如上文所述)
虽然对于HW enqueue而言free list group的优化很强大，但是从平衡而言ASSM automatic segment space managment仍比MSSM更胜一筹。
相关链接：
Leave a Reply