重庆思庄Oracle、Redhat认证学习论坛
标题: 12.2 一则事件enq: IV - contention [打印本页]
作者: 郑全 时间: 2017-6-3 01:46
标题: 12.2 一则事件enq: IV - contention
本帖最后由 郑全 于 2017-6-3 01:47 编辑
环境:exadata 双节点,oracle版本12.1.0.2
数据库服务器上多个实例出现enq: IV - contention等待事件,发现存在相关bug
In this Document
APPLIES TO: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 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
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_processes
To find out the highest value, run the following grep on each node:
ps -ef| grep lmd
通过文章可知,该bug是由于两节点cpu个数不同导致的,顿时觉得差异,按道理讲两台服务器cpu个数采购的时候应该是一致的,
于是查看cpu个数,发现果然不一致。
欢迎光临 重庆思庄Oracle、Redhat认证学习论坛 (http://bbs.cqsztech.com/) |
Powered by Discuz! X3.2 |