Oracle等待事件队列等待之enq: IV - contention案例

0    70    1

Tags:

👉 本文共约1383个字,系统预计阅读时间或需6分钟。

故障分析及解决过程

数据库环境介绍

项目source db
db 类型RAC
db version12.1.0.2.0
db 存储ASM
OS版本及kernel版本SuSE Linux Enterprise Server(SLES 11) 64位

AWR分析

Oracle等待事件队列等待之enq: IV -  contention案例

这里简单分析一下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的负载较大,而ADDM中,特殊类的等待事件较多。接下来查看等待事件的部分:

Oracle等待事件队列等待之enq: IV -  contention案例

可以看到enq: IV - contention和DFS lock handle等待较为严重。这里需要说一下enq: IV - contention这个名称。在AWR中,IV和-的前后都是1个空格,而在数据库中记录的是-之后有2个空格,如下:

Oracle等待事件队列等待之enq: IV -  contention案例

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

Oracle等待事件队列等待之enq: IV -  contention案例

根据ASH中的p1参数的值获得:

enq: IV - contention解决

Oracle等待事件队列等待之enq: IV -  contention案例

本人提供Oracle、MySQL、PG等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!

该等待事件为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。

Oracle等待事件队列等待之enq: IV -  contention案例

从dba_hist_parameter中可以看到CPU_COUNT这个参数的变化历史:

查询告警日志: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)

标签:

头像

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

4 × 2 =

 

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部
返回顶部