Oracle等待事件队列等待之enq: IV - contention案例
Tags： enq: IV - contentionOracle等待事件
故障分析及解决过程
数据库环境介绍
| 项目 | source db |
|---|---|
| db 类型 | RAC |
| db version | 12.1.0.2.0 |
| db 存储 | ASM |
| OS版本及kernel版本 | SuSE Linux Enterprise Server（SLES 11） 64位 |
AWR分析
这里简单分析一下Up Time(hrs)，其它几个指标都很熟悉了。表中的“Up Time(hrs)”代表自数据库实例启动到本次快照结束这段时间的小时数。例如，该AWR中数据库实例1的启动时间为“2016-08-11 20:51”，快照结束时间为“2016-12-14 21:00”，故“Up Time(hrs)”约为125.006天，转换为小时约为3000.14小时，如下所示：
1 2 3 4 5 | 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 |
可以看到节点1的负载较大，而ADDM中，特殊类的等待事件较多。接下来查看等待事件的部分：
可以看到enq: IV - contention和DFS lock handle等待较为严重。这里需要说一下enq: IV - contention这个名称。在AWR中，IV和-的前后都是1个空格，而在数据库中记录的是-之后有2个空格，如下：
所以，采用搜索的时候需要注意。
根据ASH中的p1参数的值获得：
1 2 3 4 5 6 7 8 9 | 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 |
enq: IV - contention解决
1 2 3 | SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIKE '%enq: IV - contention%'; |
该等待事件为12c特有，12c相比11g多了大约500多个等待事件。该问题参考MOS：12c RAC DDL Performance Issue: High "enq: IV - contention" etc if CPU Count is Different (文档 ID 2028503.1)
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个节点上的cpu_count这个变量不一致导致的。
从AWR中可以看出节点1的CPU为48，而节点2的CPU为96。
从dba_hist_parameter中可以看到CPU_COUNT这个参数的变化历史：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | 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的变化。
询问客户可知，是他们调整过系统的CPU资源，所以导致节点2上的CPU_COUNT自动变化，引起了enq: IV - contention等待。
若主机的CPU个数变化，那么当主机重启后数据库的cpu_count参数的值会随之变化，该参数属于操作系统依赖参数。
调整主机的CPU个数之后，该等待事件消失。
MOS
12c RAC DDL Performance Issue: High "enq: IV - contention" etc if CPU Count is Different (文档 ID 2028503.1)
