【故障处理】队列等待之enq IV - contention案例
1.1 BLOG文档结构图 1.2 前言部分 1.2.1 导读和注意事项各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，~O(∩_∩)O~：
① 队列等待之enq IV - contention案例（重点）
Tips：
① 本文在itpub（http://blog.itpub.net/26736162）、博客园(http://www.cnblogs.com/lhrbest)和微信公众号（xiaomaimiaolhr）上有同步更新。
② 文章中用到的所有代码、相关软件、相关资料及本文的pdf版本都请前往小麦苗的云盘下载，小麦苗的云盘地址见：http://blog.itpub.net/26736162/viewspace-1624453/。
③ 若网页文章代码格式有错乱，请下载pdf格式的文档来阅读。
④ 在本篇BLOG中，代码输出部分一般放在一行一列的表格中。
本文如有错误或不完善的地方请大家多多指正，ITPUB留言或QQ皆可，您的批评指正是我写作的最大动力。
项目
source db
db 类型
RAC
db version
12.1.0.2.0
db 存储
ASM
OS版本及kernel版本
SuSE Linux Enterprise Server（SLES 11） 64位
的启动时间为“2016-08-11 20:51”，快照结束时间为“2016-12-14 21:00”，故“Up Time(hrs)”约为125.006天，转换为小时约为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
可以看到节点1的负载较大，而ADDM中，特殊类的等待事件较多。
接下来查看等待事件的部分：
个空格，而在数据库中记录的是-之后有2个空格，如下：
所以，采用搜索的时候需要注意。
根据ASH中的p1参数的值获得：
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
SELECT *
FROM V$EVENT_NAME A
WHERE A.NAME LIKE '%enq: IV - contention%';
多个等待事件。
该问题参考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
个节点上的cpu_count这个变量不一致导致的。
的CPU为48，而节点2的CPU为96。
从dba_hist_parameter中可以看到CPU_COUNT这个参数的变化历史：
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_COUNT自动变化，引起了enq: IV - contention等待。
若主机的CPU个数变化，那么当主机重启后数据库的cpu_count参数的值会随之变化，该参数属于 *** 作系统依赖参数。
调整主机的CPU个数之后，该等待事件消失。
In this Document
Oracle Database - Enterprise Edition - Version 12.1.0.1 to 12.1.0.2 [Release 12.1]
Information in this document applies to any platform.
SYMPTOMS12c 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 Concurrencytkprof 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 CAUSECluster 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
SOLUTIONThe 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_processesTo find out the highest value, run the following grep on each node:
ps -ef| grep lmdAbout Me
...............................................................................................................................
● 本文作者：小麦苗，只专注于数据库的技术，更注重技术的运用
● 本文在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好友(642808185)，注明添加缘由
● 于 2016-09-01 15:00 ~ 2016-10-20 19:00 在农行完成
● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解
● 版权所有，欢迎分享本文，转载请保留出处
...............................................................................................................................
手机长按下图识别二维码或微信客户端扫描下边的二维码来关注小麦苗的微信公众号：xiaomaimiaolhr，免费学习最实用的数据库技术。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）