作者介紹：

孫加鵬 云和恩墨技術(shù)顧問

六年Oracle技術(shù)顧問經(jīng)驗，所服務(wù)的行業(yè)包括電信運(yùn)營商、金融業(yè)、制造業(yè)等。

擅長Oracle的故障診斷、高可用架構(gòu)、升級遷移等。目前主要服務(wù)于上海金融類客戶。

1

故障概述

2017年07月24日11:58左右，客戶核心數(shù)據(jù)庫出現(xiàn)大量活動會話，導(dǎo)致數(shù)據(jù)庫負(fù)載急劇加大，從而導(dǎo)致業(yè)務(wù)出現(xiàn)延時，DBA通過查看SESSION信息發(fā)現(xiàn)有大量的“enq: HW - contention”等待事件。

一直持續(xù)約有3分鐘，數(shù)據(jù)庫負(fù)載下降：

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

2

故障分析

1

故障現(xiàn)象

ENMODB數(shù)據(jù)庫出現(xiàn)大量活動會話，數(shù)據(jù)庫負(fù)載急劇加大，通過V$SESSION能看到大量enq：HW contention的活動會話信息，客戶緊急采集了ASH信息，方便后期故障分析。

2

分析過程

從AWR和ASH兩個維度來分析此故障，先整體后局部，首先從AWR分析入手。

1、AWR分析

首先看一下故障時間段的AWR報告：

半小時的采樣時間，DB Time 215mins，其中等待時間“enq: HW - contention”占據(jù)近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鎖是在分配高水位線以上的空閑空間時，多個進(jìn)程同時為了分配高水位線上空閑空間而修改HWM，修改HWM需要持有HW鎖，該鎖又屬于排他鎖(mode=6)。

如果大量數(shù)據(jù)被并發(fā)插入某個對象時，那多個進(jìn)程可能會試圖在高水位線以上同時申請可用空間，大并發(fā)的申請HW鎖，從而導(dǎo)致HW enqueue爭用。HW – contention等待事件的P1，P2，P3參數(shù)參考下表；

Event

P1 Parameter

P2 Parameter

Parameter 3

enq: HW - contention

name|mode

table space

# block

發(fā)現(xiàn)這個時間段確實(shí)有大量的INSERT操作，半小時采用中，該SQL執(zhí)行了約近24w次。

下一步看看HW競爭是在表段還是在索引段上？

大量的物理讀/物理寫請求也都發(fā)生在表TAB_ENMO的索引上。這里可以猜測HW競爭可能不在表上，而在這幾個索引上面，IO讀寫請求非常高。

2、ASH分析

通過客戶采集的ASH分析發(fā)現(xiàn)，等待事件“enq: HW - contention”是從07月24日11:57:12秒左右開始的，此類session全部被session id為1191的會話阻塞。

查看1191會話信息，發(fā)現(xiàn)11:57:12的時候沒有被任何會話阻塞(NOT IN WAIT)，Session狀態(tài)是ON CPU：

這個時間點(diǎn)11:57:12的時候會話1191在執(zhí)行以下的INSERT操作，這個就是源頭，并且這個SQL一直在執(zhí)行。

INSERT操作從11:57:11開始，后續(xù)該會話一直都是HW競爭，并且跟其他SESSION爭相持有HW鎖。

這個時間點(diǎn)大量的SESSION都在持續(xù)申請HW鎖，因此都在相互blocking sessions。從p1，p2，p3參數(shù)中發(fā)現(xiàn)P3值并不代表爭用塊的RDBA(data block address)(36730這個值太小了，這是為啥？先思考下)。

既然P3找不到RDBA，那就從ash中字段CURRENT_FILE#和CURRENT_BLOCK#上尋找爭用塊：

發(fā)現(xiàn)所有的HW競爭都發(fā)生在索引IDX_TAB_ENMO_SEQ上，該索引就是表TAB_ENMO上的索引，HW競爭的SQL語句也是上面AWR中發(fā)現(xiàn)的SQL。

既然是大并發(fā)持有HW鎖，多個進(jìn)程是持續(xù)不斷的申請HW鎖，說明不斷的發(fā)現(xiàn)free space不足，一般ASSM管理都是一次性分配多個extent，根據(jù)對象大小一個extent下面又會有多個block。除非指定storage參數(shù)next size 大小：

表空間ENMO_DATA是ASSM(自動段空間管理)，并且是本地管理表空間，獲取表空間的定義語句：

表空間自動擴(kuò)展NEXT SIZE 100M。段管理方式使用自動段空間管理(ASSM)。這里有個地方值得關(guān)注下，這個表空間屬于bigfile tablespace，這就是為什么通過等待事件中的p1，p2，p3參數(shù)無法精確定位到具體發(fā)生爭用的block了。

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

因此上面的P3參數(shù)指的datafile中的block number，其實(shí)就是這個索引段的段頭(segment header)所在的block。

所以HW競爭還是發(fā)生在索引的段頭上，因為段頭會記錄HWM信息，進(jìn)程修改HWM就必須要持有HW鎖，并修改索引段頭上的HWM。所以P3=36730是準(zhǔn)確的，只是這個P3參數(shù)代表是bigfile tablespace上的block number，dump出file_id=6 block_id=36730的塊，可以看出就是索引IDX_TAB_ENMO_SEQ的Segment header。

現(xiàn)在問題基本明朗了，所有的爭用都發(fā)生在索引的Segment Header上面，進(jìn)程為了需要更多的空間(unformatted)，通過持有HW鎖來修改高水位線(HWM)，大量的進(jìn)程并發(fā)從而導(dǎo)致HW鎖上的競爭。

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

索引的stroage參數(shù)中NETX=1M，即每次分配空間以每次1M大小來分配，8k塊大小即相當(dāng)于每次分配

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

顯然不是的，自動段管理表空間(ASSM)下這個NEXT擴(kuò)展字句應(yīng)該是不生效的，不會按照這樣來初始化extent的。

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

上面信息可以看出索引的extent并不是只有128個塊，跟ASSM的extent分配機(jī)制匹配的，segment后期會按照64M的大小分配extent，即每個extent有64*1024/8=8192個block。

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

同時12點(diǎn)12分左右又出現(xiàn)一次HW競爭嚴(yán)重的情況，導(dǎo)致AAS飆高，系統(tǒng)負(fù)載急劇升高。因此每次出現(xiàn)HW競爭都是因為Unformatted Blocks不夠用的時候，多個進(jìn)程修改索引段頭的HWM的時候持有HW鎖。

所以問題原因主要是多個進(jìn)程同時修改索引段頭上的HWM而導(dǎo)致的爭用，針對這種問題一般采用HASH分區(qū)索引，通過將索引改造成HASH分區(qū)索引來緩解索引段頭的爭用，這樣從原來的在單個段頭修改HWM，到現(xiàn)在的在多個分區(qū)索引的段頭上修改HWM。將原先索引從一個L3位圖管理塊，到多個L3層位圖管理塊。

先看一下ASSM的extent三層位圖管理結(jié)構(gòu)：

整個位圖三級位圖結(jié)構(gòu)是一個樹形結(jié)構(gòu)，L3往往代表的就是Segment Header，L3中記錄了所包含的所有L2位圖塊的地址，L2位圖塊中又包含了所屬L1位圖塊地址。L1位圖塊中記錄了具體數(shù)據(jù)塊的地址和使用情況。

L3，L2，L1三層結(jié)構(gòu)均以樹形結(jié)構(gòu)，一對多的關(guān)系。

下面我們來dump出索引的段頭(Segment Header)信息。

索引目前已經(jīng)有2323個extents，現(xiàn)在的高水位線在extent_id 2322 block_id 8192位置?！盠2 Hint for inserts”這表名INSERT插入的記錄從這個L2(后面跟的是bigfile的block_id)開始。

Dump出這個L2位圖塊：

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

ASSM管理表空間的Table Block的狀態(tài)有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有興趣的可以研究研究。

4

故障解決

問題原因主要是多個進(jìn)程同時修改索引段頭上的HWM而導(dǎo)致的爭用，針對這種問題一般采用HASH分區(qū)索引，通過將索引改造成HASH分區(qū)索引來緩解索引段頭的爭用，這樣從原來的在單個段頭修改HWM，到現(xiàn)在的在多個分區(qū)索引的段頭上修改HWM。

引入思考，當(dāng)初設(shè)計表的時候，從業(yè)務(wù)角度出發(fā)，知道這是一個業(yè)務(wù)流水表，流水表的特點(diǎn)就是大量的DML操作，特別是INSERT操作的存在，表級別做了分區(qū)設(shè)計，索引上未考慮到位采用了普通索引，導(dǎo)致后期性能下降和故障發(fā)生。因此好的數(shù)據(jù)庫結(jié)構(gòu)設(shè)計是有多么重要。

總結(jié)

以上是生活随笔為你收集整理的oracle dump enq hw,经典故障分析 - ASSM引发的索引争用与 enq HW -contentio的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。