合 Oracle等待事件队列等待之enq: IV - contention案例
Tags： Oracle等待事件enq: IV - contention
👉 本文共约1365个字，系统预计阅读时间或需6分钟。
故障分析及解决过程
数据库环境介绍
| 项目 | 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.
本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信dbaup66，谢谢！
