等待事件之enq: HW - contention

---

---

SELECT *
  FROM V$EVENT_NAME
 WHERE NAME  IN
       ('enq: HW - contention');


SELECT * FROM V$LOCK_TYPE D WHERE D.TYPE='HW';


主要用來控制特定物件空間分配時的併發操作。v$lock中的id1為表空間編號ts#,id2為需要分配空間的物件segment header的相對DBA(Data Block Address)位置。
爭用主要發生在高併發大量插入時，甚至表中若有LOB欄位時情況更糟，或手工對該物件ALLOCATE/DEALLOCATE空間時。HWM的推進分配新空間的速度趕不上併發會話所需空間的速度時，就會發生在HW的ENQ上的等待。
TABLE的High WaterMark（即高水位線）標識table segment中已用空間和未用空間的邊界，具體來講，HWM以上的block的狀態是：unformattedand have never been used； HWM以下的block的狀態是：Allocated, but currentlyunformatted and unused、 Formatted and contain data、Formatted and empty because the data was deleted。當HWM以下的block都無空閒空間可以使用時，Oracle會推進HWM來申請分配新的block到segment裡面，而HW enqueue鎖被用來管理推進HWM分配新空間時的序列操作。
解決思路：
?刪除無用索引。
?改造為HASH分割槽表。同一時間的併發的空間分配需求會被打散到多個分割槽段上。
?提前手工allocatenew空間（可以做成定期自動任務）。
?主動shrink回收可以重用的空間，避免業務高峰期的自動allocate競爭。
?設定表空間更大的UNIFORM SIZE，每次allocate更多extent到表的HWM之上，避免HWM劇烈時偶爾還會等在表空間的extent分配上。
?確保使用ASSM (Automatic segment spacemanagement) tablespace。
?隱含引數_bump_highwater_mark_count，可以控制HWM每次推進的block個數。但是設定該隱含引數應該得到Oracle的支援，而且對其它小表有負面影響。
?檢查IO子系統效能，有時候IO效能的變化也會導致空間分配操作緩慢，進而引發等待。
?LOB段空間的頻繁重回收，可能也會導致該競爭，針對LOB可以適當增加chunk，每次分配更多空間；也可以主動allocate 或shrink
?另外針對使用ASSM表空間的LOB有一個Bug 6376915注意檢查是否已applied fixed patch，並且要通過設定event來啟用。此event用於控制1次LOB chunk回收操作時的chunk個數（default是1），進而可以減少HWM enq等待發生的次數。
?EVENT="44951 TRACE NAME CONTEXT FOREVER, LEVEL < 1 -1024 >"


為防止多個程式同時修改HWM而提供的鎖稱為HW鎖（官方文件解釋：Space management operations on a specific segment）。想要移動HWM的程式必須獲得HW鎖。HW鎖爭用大部分是因為大量執行insert所引發的，偶爾也會因大量執行update在回滾段中發生HW鎖爭用現象。若是update，表中段的擴充套件的大小雖然不多，但在建立回滾資料的過程中，需要回滾段的急速擴張。HW鎖爭用是在段的急速空間擴張時普遍出現的等待現象，有時也會引發嚴重的效能下降。
oracle 10g起新增了in-memory undo（以下稱IMU）功能，將回滾段的資料存於共享池內的KTI-UNDO區域的功能。KTI-UNDO區域上儲存的回滾資料會由oracle被轉到（flush）回滾段。因此，從10g起，回滾段引起的HW鎖爭用比以前版本有所減少。期待撤銷塊的讀寫工作減少會給整個系統帶來改善新能的效果，但對於IMU的效能問題還不被人所知，IMU被多個in-memory undo 鎖存器保護。為了使用相同的KTI-UNDO區域，在發生爭用等待latch：in memory latch事件，關於IMU的跟多資訊參照我的部落格：http://blog.csdn.net/changyanmanman/article/details/7983162
問題1：請問如何理解"HW Enqueue是用於segment的HWM的, 可以通過手工分配extents來解決"
在手動段管理的時代，可以通過這個ALLOCATION EXTENT把新的BLOCK加入FREELIST中，也就是提高了HWM。來避免HW ENQUEUE
自動段管理我覺得這個方法已經不適用了吧~當初freelist時代，解決HW enq的辦法，就是減少hwm的提升次數~，通過alter table extent + instance子句 把新的extent中的block都加入freelist中，來達到目的。
問題2：HWM越高,每次尋找具體資料塊時就要找得越多, HW Enqueue應該越嚴重吧? 不瞭解HW Enqueue的工作方式,期望高手解答!!!
只有當新的extents需要分配的時候，才會發生HW鎖的爭用，主要明確HW鎖不是使用新的extents時候等待，而是分配extents的時候，也就是提高HWM的時候爭用，所以，一次分配更大的extents可以減少這個鎖的爭用哦。。


問題3：那是我在系統分配extents的時候存在這個等待嗎？
HW enqueue The HW enqueue is used to serialize the allocation of space beyond the high water mark of a segment.
如文件所說，HW enqueue 是發生在一個段的HWM連續提升的狀況下~ 提升HWM要做什麼工作呢？
首先HWM的位置是儲存在段頭塊，並且HWM的提升會增加Freelist中的free blocks，而freelist中的塊數的紀錄，也儲存在段頭(當然如果freelist group=n>1，那麼儲存在段頭後面的n個塊中~)，所以這個時候要修改的是段頭塊(以及freelist 所在的塊)，還有一個地方要修改，就是原來freelist中最後一個block，這個裡面記錄了freelist單項列表的最後一個地址，要把他修改，指向新加入freelist的塊的地址~還要在所有新加入freelist的塊上建立freelist單項鍊表~ 可見提高HWM是需要修改很多塊的~
但是如果新加入一個extent呢？對於字典管理表空間，需要修改資料字典等待為ST enqueue（印象中）~ 而本地管理表空間，僅僅需要修改以下資料檔案頭上的點陣圖~這個工作量是非常小的~ 我不認為分配extent會造成多大的等待~ 當然就算有等待也不是hw enqueue


問題4：對於assm，可以採用uniform，分配更大的extent——metalink的確有這個說法~ 但是我覺得更主要的是assm本身的段管理機制使用點陣圖管理本身提高了free block的併發性~ 較少了等待的發生~
但是為什麼要分配大extent我就不是很明白了~按理說大extent和hwm的提升沒什麼關係呀~
而且assm下有兩條hwm~ 所以我覺得high hwm low hwm的機制是不是也可以減少hwm變化的開銷
通過不同大小uniform測試可以看出extent大的好處。
原因應該是不必過多的分配extent，減少對HW enquence的爭用


對於HHWM和LHWM，可以參見tanel的一段話
ASSM high-HWM extensions（擴張） are not done over extent boundaries（邊界） IIRC, thus with small extents you'd have lots of extensions to do, each requiring HW-enqueue get.ASSM relieves（解除，降低） HW-enqueue contention by increasing HHWM in large sizes (depending on extent and current segment size),so less HW operations have to be done.


The LHWM extensions can be done without having HW-enqueue as they involve（包含） only changing few records in a BMB block （我估計應該是點陣圖塊，不確定）and the BMB is pinned（釘住） for that exclusively anyway. The actual batch formatting（批量格式化） of datablocks is done while having FB enqueue, allowing finer（出色的） granularity（粒度） of locking block ranges in case of multiple parallel inserts.
相關討論：http://www.itpub.net/thread-1242093-1-1.html




如何找到'事件：enq: HW - contention'對應的熱點segment
HW enqueue
The HW enqueue is used to serialize the allocation of space beyond the high water mark of a segment.
V$SESSION_WAIT.P2/V$LOCK.ID1is the tablespace number.
V$SESSION_WAIT.P3/V$LOCK.ID2is the relative dba of segment header of the object for which space is being allocated.
If this is a point of contention for an object, then manual allocation of extents solves the problem.
SQL> select p1, p2, p3 from v$session_wait where event = 'enq: HW - contention';
 P1 P2 P3
---------- ---------- ----------
1213661190 7 140003563
1213661190 7 140003563
1213661190 7 140003563
1213661190 7 140003563
1213661190 7 140003563
1213661190 7 140003563
1213661190 7 140003563
7 rows selected


SQL> select dbms_utility.data_block_address_block(140003563),
 dbms_utility.data_block_address_file(140003563)
 from dual ;


DBMS_UTILITY.DATA_BLOCK_ADDRES DBMS_UTILITY.DATA_BLOCK_ADDRES
------------------------------ ------------------------------
 1591531 33
SQL> select name from v$tablespace where ts#=7;
NAME
------------------------------
INFORES
通過下面語句找到熱點segment
select *
 from dba_extents.segment_name
 where tablespace_name = 'INFORES'
 and FILE_ID = 33
 and 1591531 between block_id and block_id + blocks

---

---

經典故障分析 - ASSM引發的索引爭用與 enq HW -contention 等待事件

2017-09-05 孫加鵬 DBGeeK

請點選此處輸入圖片描述

轉載自  資料和雲（ID：OraNews）

作者      孫加鵬

一、故障概述

2017年07月24日11:58左右，客戶核心資料庫出現大量活動會話，導致資料庫負載急劇加大，從而導致業務出現延時，DBA通過檢視SESSION資訊發現有大量的“enq: HW - contention”等待事件。

一直持續約有3分鐘，資料庫負載下降：

請點選此處輸入圖片描述

下面是詳細的故障分析診斷過程，以及詳細的解決方案描述。

二、故障分析

1故障現象

ENMODB資料庫出現大量活動會話，資料庫負載急劇加大，通過V$SESSION能看到大量enq：HW contention的活動會話資訊，客戶緊急採集了ASH資訊，方便後期故障分析。

2分析過程

從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了。

具體可以參考Mos文件：ID 2098543.1。

因此上面的P3引數指的datafile中的block number，其實就是這個索引段的段頭（segment header）所在的block。

請點選此處輸入圖片描述

所以HW競爭還是發生在索引的段頭上，因為段頭會記錄HWM資訊，程式修改HWM就必須要持有HW鎖，並修改索引段頭上的HWM。所以P3=36730是準確的，只是這個P3引數代表是bigfile tablespace上的block number，dump出file_id=6 block_id=36730的塊，可以看出就是索引IDX_TAB_ENMO_SEQ的Segment header。

現在問題基本明朗了，所有的爭用都發生在索引的Segment Header上面，程式為了需要更多的空間（unformatted），通過持有HW鎖來修改高水位線（HWM），大量的程式併發從而導致HW鎖上的競爭。

那既然是ASSM管理，為何新的extent分配的時候還會出現HWM上的競爭呢？不都是bitmap管理了嗎？比之前freelist管理要好很多啊，看看這個索引的DDL語句：

請點選此處輸入圖片描述

索引的stroage引數中NETX=1M，即每次分配空間以每次1M大小來分配，8k塊大小即相當於每次分配

128個blocks。難道是客戶建立索引的時候指定extent分配大小？問題是不是發生在這個NEXT 1M上面呢？

顯然不是的，自動段管理表空間（ASSM）下這個NEXT擴充套件字句應該是不生效的，不會按照這樣來初始化extent的。

可以檢查下索引的extent分佈，看看extent下面包含多少個blocks。

請點選此處輸入圖片描述

上面資訊可以看出索引的extent並不是只有128個塊，跟ASSM的extent分配機制匹配的，segment後期會按照64M的大小分配extent，即每個extent有64*1024/8=8192個block。

7月24日故障之後幾天，又不間斷的出過2~3次同樣的故障，那為何不間斷的會發生這種故障？索引真的有這麼需要unformatted空間嗎？表上有大量的INSERT操作的同時也需要維護索引，同時索引也會進行分裂，不論是leaf node split還是branch node split，都需要新塊來滿足分裂，實驗證明索引分裂只請求unformatted的塊，未滿塊或空閒塊都不會使用。下面來看看索引上unformatted塊的使用情況，這個show_space儲存過程來自TOM大師的分享：

請點選此處輸入圖片描述

請點選此處輸入圖片描述

請點選此處輸入圖片描述

同時12點12分左右又出現一次HW競爭嚴重的情況，導致AAS飆高，系統負載急劇升高。因此每次出現HW競爭都是因為Unformatted Blocks不夠用的時候，多個程式修改索引段頭的HWM的時候持有HW鎖。

所以問題原因主要是多個程式同時修改索引段頭上的HWM而導致的爭用，針對這種問題一般採用HASH分割槽索引，通過將索引改造成HASH分割槽索引來緩解索引段頭的爭用，這樣從原來的在單個段頭修改HWM，到現在的在多個分割槽索引的段頭上修改HWM。將原先索引從一個L3點陣圖管理塊，到多個L3層點陣圖管理塊。

先看一下ASSM的extent三層點陣圖管理結構：

請點選此處輸入圖片描述

整個點陣圖三級點陣圖結構是一個樹形結構，L3往往代表的就是Segment Header，L3中記錄了所包含的所有L2點陣圖塊的地址，L2點陣圖塊中又包含了所屬L1點陣圖塊地址。L1點陣圖塊中記錄了具體資料塊的地址和使用情況。

L3，L2，L1三層結構均以樹形結構，一對多的關係。

下面我們來dump出索引的段頭（Segment Header）資訊。

請點選此處輸入圖片描述

請點選此處輸入圖片描述

索引目前已經有2323個extents，現在的高水位線在extent_id 2322 block_id 8192位置。”L2 Hint for inserts”這表名INSERT插入的記錄從這個L2（後面跟的是bigfile的block_id）開始。

Dump出這個L2點陣圖塊：

請點選此處輸入圖片描述

請點選此處輸入圖片描述

如上，這個L2中包含有1007個L1，free L1有77個，L1共有三個狀態值，分別為Free 1，Free 3和Free 5，3和5都代表該L1下面有空塊。

請點選此處輸入圖片描述

ASSM管理表空間的Table Block的狀態有7種，分別是：

0 = unformatted

1 = logically full (per pctfree)

2 = 0-25% free

3 = 25-50% free

4 = 50%-75% free

5= 75-100% free

對於Block的DUMP有興趣的可以研究研究。

三、故障解決

問題原因主要是多個程式同時修改索引段頭上的HWM而導致的爭用，針對這種問題一般採用HASH分割槽索引，通過將索引改造成HASH分割槽索引來緩解索引段頭的爭用，這樣從原來的在單個段頭修改HWM，到現在的在多個分割槽索引的段頭上修改HWM。

引入思考，當初設計表的時候，從業務角度出發，知道這是一個業務流水錶，流水錶的特點就是大量的DML操作，特別是INSERT操作的存在，表級別做了分割槽設計，索引上未考慮到位採用了普通索引，導致後期效能下降和故障發生。因此好的資料庫結構設計是有多麼重要。

---

---

About Me

............................................................................................................................................. ● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除 ● 本文在itpub（http://blog.itpub.net/26736162/abstract/1/）、部落格園（http://www.cnblogs.com/lhrbest）和個人微信公眾號（xiaomaimiaolhr）上有同步更新 ● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/ ● 本文部落格園地址：http://www.cnblogs.com/lhrbest ● 本文pdf版、個人簡介及小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址：http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826 ............................................................................................................................................. ● QQ群號：230161599（滿）、618766405 ● 微信群：可加我微信，我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友（646634621），註明新增緣由 ● 於 2017-09-01 09:00 ~ 2017-09-30 22:00 在魔都完成 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ............................................................................................................................................. ● 小麥苗的微店：https://weidian.com/s/793741433?wfr=c&ifr=shopdetail ● 小麥苗出版的資料庫類叢書：http://blog.itpub.net/26736162/viewspace-2142121/ ............................................................................................................................................. 使用微信客戶端掃描下面的二維碼來關注小麥苗的微信公眾號（xiaomaimiaolhr）及QQ群（DBA寶典），學習最實用的資料庫技術。    小麥苗的微信公眾號      小麥苗的DBA寶典QQ群1     小麥苗的DBA寶典QQ群2        小麥苗的微店 .............................................................................................................................................

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2144992/，如需轉載，請註明出處，否則將追究法律責任。