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上这种持有周期更短，但这仍是一个串行化的扩展过程。   

本文转自maclean_007 51CTO博客，原文链接:http://blog.51cto.com/maclean/1277698