溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

【故障處理】隊列等待之enq IV - contention案例

發(fā)布時間:2020-07-03 01:00:41 來源:網(wǎng)絡(luò) 閱讀:744 作者:小麥苗best 欄目:數(shù)據(jù)庫

【故障處理】隊列等待之enq IV -  contention案例

1.1  BLOG文檔結(jié)構(gòu)圖

【故障處理】隊列等待之enq IV -  contention案例 

1.2  前言部分

1.2.1  導(dǎo)讀和注意事項

各位技術(shù)愛好者,看完本文后,你可以掌握如下的技能,也可以學(xué)到一些其它你所不知道的知識,~O(∩_∩)O~

隊列等待之enq IV -  contention案例(重點)

Tips

本文在itpubhttp://blog.itpub.net/26736162)、博客園(http://www.cnblogs.com/lhrbest)和微信公眾號(xiaomaimiaolhr有同步更新。

文章中用到的所有代碼相關(guān)軟件、相關(guān)資料及本文的pdf版本都請前往小麥苗的云盤下載,小麥苗的云盤地址見:http://blog.itpub.net/26736162/viewspace-1624453/。

若網(wǎng)頁文章代碼格式有錯亂,下載pdf格式的文檔來閱讀

本篇BLOG,代碼輸出部分一般放在一行一列的表格中。

本文如有錯誤或不完善的地方請大家多多指正,ITPUB留言或QQ皆可,您的批評指正是我寫作的最大動力。

 

 

1.3  故障分析及解決過程

 

1.3.1  數(shù)據(jù)庫環(huán)境介紹

 

項目

source db

db 類型

RAC

db version

12.1.0.2.0

db 存儲

ASM

OS版本及kernel版本

SuSE Linux Enterprise Server(SLES 1164

 

1.3.2  AWR分析

【故障處理】隊列等待之enq IV -  contention案例 

這里簡單分析一下Up Time(hrs),其它幾個指標(biāo)都很熟悉了。表中的“Up Time(hrs)”代表自數(shù)據(jù)庫實例啟動到本次快照結(jié)束這段時間的小時數(shù)。例如,該AWR中數(shù)據(jù)庫實例1的啟動時間為“2016-08-11 20:51”,快照結(jié)束時間為“2016-12-14 21:00”,故“Up Time(hrs)”約為125.006天,轉(zhuǎn)換為小時約為3000.14小時,如下所示:

SYS@lhrdb> SELECT trunc(UP_TIME_D,3),  trunc(trunc(UP_TIME_D,3)*24,2) UP_TIME_HRS FROM (SELECT (TO_DATE('2016-12-14 21:00', 'YYYY-MM-DD HH24:MI') - TO_DATE('2016-08-11 20:51', 'YYYY-MM-DD HH24:MI'))  UP_TIME_D FROM DUAL);

 

TRUNC(UP_TIME_D,3) UP_TIME_HRS

------------------ -----------

           125.006     3000.14

 

可以看到節(jié)點1的負(fù)載較大,而ADDM中,特殊類的等待事件較多。接下來查看等待事件的部分:

【故障處理】隊列等待之enq IV -  contention案例 

可以看到enq: IV - contention和DFS lock handle等待較為嚴(yán)重。這里需要說一下enq: IV - contention這個名稱。在AWR中,IV-的前后都是1個空格,而在數(shù)據(jù)庫中記錄的是-之后有2個空格,如下:

【故障處理】隊列等待之enq IV -  contention案例 

所以,采用搜索的時候需要注意。

【故障處理】隊列等待之enq IV -  contention案例 

根據(jù)ASH中的p1參數(shù)的值獲得:

SYS@lhrdb> SELECT CHR(BITAND(1230372867, -16777216) / 16777215) ||

  2         CHR(BITAND(1230372867, 16711680) / 65535) "LOCK",

  3         BITAND(1230372867, 65535) "MODE"

  4    FROM DUAL;

 

LO       MODE

-- ----------

IV          3

 

 

1.3.3  enq: IV -  contention解決

    SELECT *

      FROM V$EVENT_NAME A

     WHERE A.NAME LIKE '%enq: IV -  contention%';

【故障處理】隊列等待之enq IV -  contention案例 

該等待事件為12c特有,12c相比11g多了大約500多個等待事件。該問題參考MOS12c RAC DDL Performance Issue: High "enq: IV - contention" etc if CPU Count is Different (文檔 ID 2028503.1)

【故障處理】隊列等待之enq IV -  contention案例

The fix will be included in future PSU, patch exists for certain platform/version.

The workaround is to set the following parameter to the highest value in the cluster and restart:

_ges_server_processes

To find out the highest value, run the following grep on each node:

ps -ef| grep lmd

 

該等待事件主要是由于12c RAC的2個節(jié)點上的cpu_count這個變量不一致導(dǎo)致的。

AWR中可以看出節(jié)點1CPU48,而節(jié)點2CPU96。

【故障處理】隊列等待之enq IV -  contention案例 

dba_hist_parameter中可以看到CPU_COUNT這個參數(shù)的變化歷史:

 

SQL> SHOW PARAMETER CPU  

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

cpu_count                            integer     96

parallel_threads_per_cpu             integer     2

resource_manager_cpu_allocation      integer     96

 

 

SQL>  select snap_id, INSTANCE_NUMBER,PARAMETER_NAME,VALUE from dba_hist_parameter where PARAMETER_NAME='cpu_count' order by snap_id;

 

   SNAP_ID INSTANCE_NUMBER PARAMETER_NAME                                                   VALUE

---------- --------------- ---------------------------------------------------------------- ------

。。。。。。。。。。。。。。。。。。。。。。。。。。。

      3368               1 cpu_count                                                        48

      3369               1 cpu_count                                                        48

      3369               2 cpu_count                                                        48

      3370               1 cpu_count                                                        48

      3371               1 cpu_count                                                        48

      3372               1 cpu_count                                                        48

      3373               1 cpu_count                                                        48

      3374               1 cpu_count                                                        48

      3375               2 cpu_count                                                        96

      3375               1 cpu_count                                                        48

      3376               1 cpu_count                                                        48

      3376               2 cpu_count                                                        96

      3377               1 cpu_count                                                        48

      3377               2 cpu_count                                                        96

      3378               2 cpu_count                                                        96

      3378               1 cpu_count                                                        48

      3379               1 cpu_count                                                        48

      3379               2 cpu_count                                                        96

。。。。。。。。。。。。。。。。。。。。

 

 

 

查詢告警日志:more alert*|grep -i Cpu  也可以獲取CPU的變化。

詢問客戶可知,是他們調(diào)整過系統(tǒng)的CPU資源,所以導(dǎo)致節(jié)點2上的CPU_COUNT自動變化,引起了enq: IV -  contention等待。

若主機的CPU個數(shù)變化,那么當(dāng)主機重啟后數(shù)據(jù)庫的cpu_count參數(shù)的值會隨之變化,該參數(shù)屬于操作系統(tǒng)依賴參數(shù)。

調(diào)整主機的CPU個數(shù)之后,該等待事件消失。

 

1.4  MOS

1.4.1  12c RAC DDL Performance Issue: High "enq: IV - contention" etc if CPU Count is Different (文檔 ID 2028503.1)


【故障處理】隊列等待之enq IV -  contention案例

In this Document


Symptoms

Cause

Solution

References



APPLIES TO:

Information in this document applies to any platform.

SYMPTOMS

12c RAC database seeing high "enq: IV - contention":


From awr report:

Top 10 Foreground Events by Total Wait Time
===================================
Event Waits Total Wait Time (sec) Wait Avg(ms) % DB time Wait Class
enq: IV - contention 52,914 1688.4 31.91 42.8 Other
row cache lock 44,865 896.8 19.99 22.7 Concurrency

 

tkprof of 10046 trace of SQL statement shows the same event in the top:

Event waited on Times Max. Wait Total Waited 
---------------------------------------- Waited ---------- ------------ 
enq: IV - contention 6017 0.32 287.68 
row cache lock 957 0.20 7.48 
library cache lock 631 0.13 15.10 
library cache pin 616 0.11 14.54

 

 

CAUSE

Cluster nodes have different CPU count resulting in different number of LMD processes, on one node it has two while on the other it has three.

The issue is due to the following bug:

BUG 21293056 - PERFORMANCE DEGRADATION OF GRANT STATEMENT AFTER 12C UPGRADE

Which is closed as duplicate of:

BUG 21395269 - ASYMMETRICAL LMDS CONFIGURATION IN A CLUSTER LEADS TO POOR MESSAGE TRANSFER

 

 

SOLUTION

The fix will be included in future PSU, patch exists for certain platform/version.

The workaround is to set the following parameter to the highest value in the cluster and restart:

ps -ef| grep lmd

 


 

About Me

...............................................................................................................................

本文作者:小麥苗,只專注于數(shù)據(jù)庫的技術(shù),更注重技術(shù)的運用

本文在itpub(http://blog.itpub.net/26736162)、博客園(http://www.cnblogs.com/lhrbest)和個人微信公眾號(xiaomaimiaolhr)上有同步更新

本文itpub地址:http://blog.itpub.net/26736162/viewspace-2131320/

本文博客園地址:http://www.cnblogs.com/lhrbest/p/6218042.html

本文pdf小麥苗云盤地址:http://blog.itpub.net/26736162/viewspace-1624453/

● QQ群:230161599     微信群:私聊

聯(lián)系我請加QQ好友(642808185),注明添加緣由

2016-09-01 15:00 ~ 2016-10-20 19:00農(nóng)行完成

文章內(nèi)容來源于小麥苗的學(xué)習(xí)筆記,部分整理自網(wǎng)絡(luò),若有侵權(quán)或不當(dāng)之處還請諒解

版權(quán)所有,歡迎分享本文,轉(zhuǎn)載請保留出處

...............................................................................................................................

手機長按下圖識別二維碼或微信客戶端掃描下邊的二維碼來關(guān)注小麥苗的微信公眾號:xiaomaimiaolhr,免費學(xué)習(xí)最實用的數(shù)據(jù)庫技術(shù)。

【故障處理】隊列等待之enq IV -  contention案例

 

【故障處理】隊列等待之enq IV -  contention案例cdn.qqmail.com/zh_CN/htmledition/p_w_picpaths/function/qm_open/ico_mailme_02.png">

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI