博客访问： 2677593
博文数量： 1137
注册时间：
Oracle 10g OCM
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Linux
Diagnoing BUG 5016142 enqueue ENQ - SS contention [ID ]
In this Document
Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.1 to 10.2.0.2 - Release: 9.2 to 10.2Information in this document applies to any platform.PurposeThis note provides additional details that will help to identify if a database is having problems introduced by Bug 5016142.Last Review DateFebruary 26, 2007Instructions for the ReaderA Troubleshooting Guide is provided to assist
in debugging a specific issue. When possible, diagnostic tools are included in the document
to assist in troubleshooting.Troubleshooting DetailsBug Description: 5016142When SMON is cleaning up very large dead transactions, it may not service other work like cleaning up temporary space, handling sort-segment requests or performing instance recovery. This fix ensures that transaction recovery is interrupted to perform. other critical work at timely intervals.The solution is to apply the patch which is available for different versions on different platforms
Unpublished Bug 5016142 is fixed in
11.1.0.6, 10.2.0.3 and 9.2.0.8 (Server Patch Set)For more information see:
Bug 5016142 - SMON rollback of large transactions blocks other actions The following information provides additional details in order to help to identify the bug.Diagnostic detailsThose are some wait events that could be present:Many sessions waiting for enqueue ENQ - SS contentionSome sessions waiting for waiting event sort segment requestA process that requires to use a sort segment, needs to get this enqueue.
SMON will grant access , but it could be delayed if SMON is busy running other tasks.
To check which processes are waiting for SS enqueue, execute:SQL>select sid,p1,p2,p3 from v$session_wait where event like 'ENQ - SS%'
and wait_time=0;The following table describes the meaning of the arguments:p2p3argumenttablespace_number1Local enqueue, to notify SMON to request some action for tablespaceidentified by tablespace idtablespace_number2Global enqueue, to release space for releasing space in tablespaceidentified by tablespace idThe name of the tablespace can be obtained by executing:SQL>select ts#,name from ts$ where ts#=;Who is holding the SS enqueueNow that the process waiting for the SS enqueue has been identified, the following query will show the process that is holding it:SQL>select sid,id1,id2,lmode,request from v$lock where type='SS' and lmode !=0;The contention is caused because the session holding the enqueue will be waiting for some resource.
In this particular case, it will be waiting for the event "Sort Segment Request".
Run the following
query to determine the waiting event:select event,p1,p2,p3 from v$session_wait where sid=;How access to SS enqueue is grantedSMON process is responsible to grant access to this enqueue, but the request will be enqueued when SMON is busy doing large operations.There are different ways to identify the activity of SMON:Using view v$session_wait to identify waiting events.
A list of some events is:
p3buffer busy waitsfile#block#db file sequential readfile#block#Wait for stopper event to be increasedThe argument p2 is very important for the two first wait events.
If the datafile belongs to UNDO tablespace, it is an indication SMON is doing a rollback operation (rollback long transaction, shrinking undo segments, etc).
If the datafile belongs to a temporary tablespace, it could be an indication SMON is dropping temporary segments.Dumping errorstack for SMON processsql>oradebug setospid sql>oradebug unlimitsql>oradebug dump errorstack 10### Wait 1 minutesql>oradebug dump errorstack 10sql>oradebug tracefile_name
When reviewing the trace file, there are key functions that should be present in the
Call Stack:
ktprbeg, kturax, functions associated to transaction rollback.The event "wait for stopper event to be increased" is an idle event and it could be an indication that SMON is not doing any activity.
But it has been observed that even if SMON
reports this idle event for a long period, SMON is not able to attend the request for the SS enqueue.NOTE: When applying the patch on Solaris, if using an old version of Opatch, the procedure will fail. Please apply patch for
before applying patch for
相关内容…
阅读(5057) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。ORACLE&等待事件--《深入浅出ORACLE第八章》
等待事件--《深入浅出ORACLE第八章》 (
等待事件的源起
等待事件的概念大概是从ORACLE 7.0.12中引入的，大致有100个等待事件。在ORACLE
8.0中这个数目增大到了大约150个，在ORACLE 8I中大约有220个事件，在ORACLE
9IR2中大约有400个等待事件，而在最近ORACLE 10GR2中，大约有874个等待事件。
虽然不同版本和组件安装可能会有不同数目的等待事件，但是这些等待事件都可以通过查询V$EVENT_NAME视图获得：
SQL& select * from v$
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 -
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 & Production
SQL& select count(*) from v$event_
----------
ORACLE的等待事件，主要可以分为两类，即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件。空闲等待事件指ORACLE正等待某种工作，在诊断和优化数据库的时候，不用过多注意这部分事件。非空闲等待事件专门针对ORACLE的活动，指数据库任务或应用运行过程中发生的等待，这些等待事件是在调整数据库的时候需要关注与研究的。
下面来看一下ORACLE 10GR2中主要分类及各类等待事件的个数：
SQL& select wait_class#,wait_class_id,wait_class,count(*)
as "count"
2 from v$event_name
3 group by wait_class#,wait_class_id,wait_class
4 order by wait_class#;
WAIT_CLASS# WAIT_CLASS_ID WAIT_CLASS count
----------- ------------- ------------------------------
----------
Application 12
Configuration 23
Administrative 46
Concurrency 24
Network 26
User I/O 17
System I/O 24
Scheduler 2
WAIT_CLASS# WAIT_CLASS_ID WAIT_CLASS count
----------- ------------- ------------------------------
----------
Cluster 47
12 rows selected.
几个视图的总结：
V$SESSION 代表数据库活动的开始，视为源起。
V$SESSION_WAIT 视图用以实时记录活动SESSION的等待情况，是当前信息。
V$SESSION_WAIT_HISTORY
是对V$SESSION_WAIT的简单增强，记录活动SESSION的最近10次等待。
V$ACTIVE_SESSION_HISTORY
是ASH的核心，用以记录活动SESSION的历史等待信息，每秒采样一次，这部分内容记录在内存中，期望值是记录一个小时的内容。
WRH#_ACTIVE_SESSION_HISTORY
是V$ACTIVE_SESSION_HISTORY在AWR的存储地。V$ACTIVE_SESSION_HISTORY中的信息会被定期(每小时一次)的刷新到负载库中，并缺省保留一个星期用于分析。
DBA_HIST_ACTIVE_SESS_HISTORY视图是WRH#_ACTIVE_SESSION_HISTORY视图和其他几个视图的联合展现，通常通过这个视图进行历史数据的访问。
V$SYSTEM_EVENT
由于V$SESSION记录的是动态信息，和SESSION的生命周期相关，而并不记录历史信息，所以ORACLE提供视图V$SYSTEM_EVENT来记录数据库自启动以来所有等待事件的汇总信息。通过这个视图，用户可以迅速获得数据库运行的总体概况。
当数据库出现瓶颈时，通常可以从V$SESSION_WAIT找到那些正在等待资源的SESSION，通过SESSION的SID，联合V$SESSION和V$SQLTEXT视图就可以捕获这些SESSION正在执行的SQL语句。
重要等待事件
Db file sequential read（数据文件顺序读取）
Db file sequential
read是个非常常见的I/O相关的等待事件，通常显示与单个数据块相关的读取操作，在大多数情况下，读取一个索引块或者通过索引读取一个数据块时，都会记录这个等待。
这个等待事件有3个参数P1、P2、P3，其中P1代表Oracle要读取的文件的绝对文件号，P2代表Oracle从这个文件中开始读取的起始数据块块号，P3代表读取的Block数量，通常这个值为1，表明是单个Block被读取。
SQL& select name,parameter1,parameter2,parameter3
2 from v$event_name where name='db file sequential
----------------------------------------------------------------
PARAMETER1
----------------------------------------------------------------
PARAMETER2
----------------------------------------------------------------
PARAMETER3
----------------------------------------------------------------
db file sequential read
如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，可能没有正确的使用驱动表；或者可能索引的使用存在问题，并非索引总是最好的选择。
在大多数情况下，通过索引可以更为快速地获取记录，所以对于一个编码规范、调整良好的数据库，这个等待事件很大通常是正常的。但是在很多情况下，使用索引并不是最佳的选择，比如读取较大表中大量的数据，全表扫描可能会明显快于索引扫描，所以在开发中就应该注意，对于这样的查询应该避免使用索引扫描。
从Oracle 9iR2开始，Oracle引入了段级统计信息收集的新特性，收集的统计信息共有11类：
Select * from v$segstat_
在Oracle 10gR2中，这类统计信息增加为15个。
对于CBO模式下的数据库，应当及时收集统计信息，使SQL可以选择正确的执行计划，避免因为统计信息陈旧而导致的执行错误等。
Db file scattered read（数据文件离散读取）
SQL& select * from v$event_name where name='db file
scattered read';
EVENT# NAME
----------
----------------------------------------------------------------
PARAMETER1
----------------------------------------------------------------
PARAMETER2
----------------------------------------------------------------
PARAMETER3
----------------------------------------------------------------
188 db file scattered read
从V$EVENT_NAME视图可以看到，该事件有3个参数，分别代表文件号、起始数据块号、数据块的数量。
起始数据块号加上数据块的数量，这意味着Oracle
session正在等待多块连续读操作的完成。这个操作可能与全表扫描（Full table scan）或者快速全索引扫描（Index
Fast Full Scan）的连续读取相关。根据经验，通常大量的db file scattered
read等待可能意味着应用问题或者索引缺失。
在实际环境的诊断过程中，可以通过v$session_wait视图发现session的等待，再结合其他视图找到存在问题的SQL等根本原因，从而从根本上解决问题。当这个等待事件比较显著时，也可结合v$session_longops动态性能视图来进行诊断，该视图记录了长时间（运行时间超过6秒的）运行的事务。
从Oracle 9i开始，Oracle新增加了一个视图V$SQL_PLAN用于记录当前系统Library
Cache中SQL语句的执行计划，可以通过这个视图找到存在问题的SQL语句。
通过V$SQL_PLAN视图，可以获得大量有用的信息：
获得全表扫描的对象
Select distinct object_name,object_owner from v$sql_plan
Where p.operation=’TABLE ACCESS’and p.options=’FULL’ and
object_owner=’SCOTT’;
获得全索引扫描的对象
Select distinct object_name,object_owner from v$sql_plan
Where p.operation=’INDEX’ and p.options=’FULL SCAN’ and
object_owner=’SCOTT’;
通过V$SQL_PLAN和V$SQLTEXT联合，获得全表扫描的SQL语句
Select sql_text from v$sqltext t,v$sql_plan p
Where t.hash_value=p.hash_value
And p.operation=’TABLE ACCESS’
And p.options=’FULL’
Order by p.hash_value,t.
Direct path read/write（直接路径读/写）
直接路径读通常发生在Oracle直接读取数据到PGA时，这个读取不需要经过SGA。直接路径读等待事件的3个参数分别是：file#（指绝对文件号）、first
block#和block数量。
这类读取通常在以下情况被使用：
磁盘排序IO操作
并行查询从属进程
最常见的是第一种情况。在DSS系统中，存在大量的Direct path
read是很正常的，但是在OLTP系统中，通常显著的直接路径读都意味着系统应用存在问题，从而导致大量的磁盘排序读取操作。
直接路径写通常发生在Oracle直接从PGA写数据到数据文件或临时文件，这个写操作可以绕过SGA。直接路径写等待事件的3个参数分别是：file#（指绝对文件号）、first
block#和block数量。
这类读取通常在以下情况被使用：
直接路径加载
并行DML操作
对未缓存的“LOB”段的写入，随后会记录为direct path write(lob)等待
最常见的直接路径写，多数因为磁盘排序导致。对于这一写入等待，应该找到I/O操作最为频繁的数据文件（如果有过多的排序操作，很有可能就是临时文件），分散负载，加快其写入操作。
如果系统存在过多的磁盘排序，会导致临时表空间操作频繁，对于这种情况，可以考虑为不同用户分配不同的临时表空间，使用多个临时文件，写入不同磁盘或者裸设备，从而降低竞争提高性能。
日志文件相关等待
SQL& select name from v$event_name where name like
----------------------------------------------------------------
log switch/archive
log file sequential read
log file single write
log file parallel write
log buffer space
log file switch (checkpoint incomplete)
log file switch (archiving needed)
log file switch (clearing log file)
switch logfile command
log file switch completion
log file sync
STREAMS capture process waiting for archive log
已选择12行。
Log File Switch（日志文件切换）
Switch当日志文件发生切换时出现，在数据库进行日志切换时，LGWR需要关闭当前日志组，切换并打开下一个日志组，在这个切换过程中，数据库的所有DML操作都处于停顿状态，直至这个切换完成。
Log File Switch主要包含两个子事件：
log file switch(achiving needed)，即日志切换（需要归档）
这个等待事件出现时通常是因为日志组循环写满以后，在需要覆盖先前日志时，发现日志归档尚未完成，出现该等待。由于Redo不能写出，该等待出现时，数据库将陷于停顿状态。
出现该等待，可能表示I/O存在问题、归档进程写出缓慢，也有可能是日志组设置不合理等原因导致。针对不同原因，可以考虑采用的解决方法有：
可以考虑增大日志文件和增加日志组；
移动归档文件到快速磁盘；
调整log_archive_max_processes参数等；
log file switch(checkpoint incomplete)，即日志切换（检查电未完成）
当所有的日志组都写满之后。LGWR试图覆盖某个日志文件，如果这时数据库没有完成写出由这个日志文件所保护的脏数据时（检查点未完成），该等待事件出现。该等待出现时，数据库同样将陷于停顿状态。
该等待事件通常表示DBWR写出速度太慢或者I/O存在问题。为解决该问题，可能需要考虑增加额外的DBWR或者增加日志组或日志文件大小。
Log File Sync（日志文件同步）
当一个用户提交或回滚数据时，LGWR将会话期的重做由日志缓冲区写入到重做日志中，LGWR完成任务以后会通知用户进程。日志文件同步过程（Log
File Sync）必须等待这一过程成功完成。对于回滚操作，该事件记录从用户发出Rollback命令道回滚完成的时间。
如果该等待过多，可能说明LGWR的写出效率低下，或者系统提交过于频繁。针对该问题，可以通过log file parallel
write等待事件或User Commits、User Rollback等统计信息来观察提交或回滚次数。
可能的解决方案主要有：
提高LGWR性能，尽量使用快速磁盘，不要把redo log file存放在RAID5的磁盘上；
使用批量提交；
适当使用NOLOGGING/UNRECOVERABLE等选项
Log File Single Write
该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列号（Log
switch）时。头块写单个进行，因为头块的部分信息是文件号，每个文件不同。
Log File Parallel Write
从Log Buffer写Redo记录到日志文件，主要指常规写操作（相对于Log File Sync）。如果Log
Group存在多个组成员，当Flush Log Buffer时，写操作是并行的，这时候此等待事件可能出现。
Log Buffer Space（日志缓冲空间）
当数据库产生日志的速度比LGWR的写出速度快，或者当日志切换太慢时，就会发生这种等待。这个等待出现时，通常表明Redo
log buffer过小，为解决这个问题，可以考虑增大日志文件的大小或者增加日志缓冲器的大小。
另一个可能的原因是磁盘I/O存在瓶颈，可以考虑使用写入速度更快的磁盘。在允许的条件下设置，可以考虑使用裸设备来存放日志文件，提高写入效率。在一般的系统中，最低的标准是，不要把日志文件和数据文件存放在一起，因为通常日志文件只写不读，分离存放可以获得性能提升，尽量使用RAID10而不是RAID5磁盘来存储日志文件。
Enqueue(队列等待)
Enqueue是一种保护共享资源的锁定机制。该锁定机制保护共享资源，以避免因并发操作而损坏数据，比如通过锁定保护一行记录，避免多个用户同时更新。Enqueue采用排队机制，即FIFO(先进先出)来控制资源的使用。
Enqueue是一组锁定事件的集合，如果数据库中这个等待事件比较显著，还需要进一步追踪是哪一个类别的锁定引发了数据库等待。
SQL& select name,wait_class
2 from v$event_name where name like '%enq%'
3 and rownum&11; --这里记录很多 只去取出了前10条而已
NAME WAIT_CLASS
------------------------------
------------------------------
enq: PW - flush prewarm buffer Application
enq: RO - contention Application
enq: RO - fast object reuse Application
enq: KO - fast object checkpoi Application
enq: TM - contention Application
enq: ST - contention Configuration
enq: HW - contention Configuration
NAME WAIT_CLASS
------------------------------
------------------------------
enq: SS - contention Configuration
enq: TX - row lock contention Application
enq: TX - allocate ITL entry Configuration
10 rows selected.
Latch Free(闩锁释放)
Free通常被称为闩锁释放，这个名称常常引起误解，实际上应该在前面加上一个”等待(WAIT)”，当数据库出现这个等待时，说明有进程正在等待某个Latch被释放，也就是Waiting
Latch Free。
Latch是一种低级排队(串行)机制，用于保护SGA中共享内存结构。Latch就像是一种快速的被获取和释放的内存锁，用于防止共享内存结构被多个用户同时访问。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。【故障处理】队列等待之enq IV -& contention案例
&BLOG文档结构图
&导读和注意事项
各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，~O(∩_∩)O~：
队列等待之enq IV -& contention案例（重点）
本文在itpub（）、博客园()和微信公众号（xiaomaimiaolhr）上有同步更新。
文章中用到的所有代码、相关软件、相关资料及本文的pdf版本都请前往小麦苗的云盘下载，小麦苗的云盘地址见：。
若网页文章代码格式有错乱，请下载pdf格式的文档来阅读。
在本篇BLOG中，代码输出部分一般放在一行一列的表格中。
本文如有错误或不完善的地方请大家多多指正，ITPUB留言或QQ皆可，您的批评指正是我写作的最大动力。
&故障分析及解决过程
&数据库环境介绍
db version
12.1.0.2.0
OS版本及kernel版本
SuSE Linux&Enterprise
Server（SLES 11）
这里简单分析一下Up
Time(hrs)，其它几个指标都很熟悉了。表中的“Up Time(hrs)”代表自数据库实例启动到本次快照结束这段时间的小时数。例如，该AWR中数据库实例1的启动时间为“
20:51”，快照结束时间为“ 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('
21:00', 'YYYY-MM-DD HH24:MI') - TO_DATE(' 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参数的值获得：
SYS@lhrdb& SELECT CHR(BITAND(, -) / ) ||
& 2&&&&&&&& CHR(BITAND(, ) / 65535) &LOCK&,
& 3&&&&&&&& BITAND(, 65535) &MODE&
& 4&&& FROM DUAL;
LO&&&&&& MODE
-- ----------
IV&&&&&&&&& 3
&enq: IV -& contention解决
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 )
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这个参数的变化历史：
SQL& SHOW PARAMETER CPU&&
NAME&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& TYPE&&&&&&& VALUE
------------------------------------ ----------- ------------------------------
cpu_count&&&&&&&&&&&&&&&&&&&&&&&&&&& integer&&&& 96
parallel_threads_per_cpu&&&&&&&&&&&& integer&&&& 2
resource_manager_cpu_allocation&&&&& integer&&&& 96
select snap_id, INSTANCE_NUMBER,PARAMETER_NAME,VALUE from dba_hist_parameter where PARAMETER_NAME='cpu_count' order by snap_
&& 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&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&&& 3375&&&&&&&&&&&&&& 1 cpu_count&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 48
&&&&& 3376&&&&&&&&&&&&&& 1 cpu_count&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 48
&&&&& 3376&&&&&&&&&&&&&& 2 cpu_count&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&&& 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个数之后，该等待事件消失。
&12c RAC DDL Performance Issue: High &enq: IV - contention& etc
if CPU Count is Different (文档 ID )
In this Document
APPLIES TO:
Information in this document applies to any platform.
12c 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 .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
row cache lock 957 0.20 7.48&
library cache lock 631 0.13 15.10&
library cache pin 616 0.11 14.54
Cluster 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:
&- PERFORMANCE DEGRADATION
OF GRANT STATEMENT AFTER 12C UPGRADE
Which is closed as duplicate of:
- ASYMMETRICAL LMDS CONFIGURATION IN A CLUSTER LEADS TO POOR MESSAGE TRANSFER
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:
ps -ef| grep lmd
...............................................................................................................................
本文作者：小麦苗，只专注于数据库的技术，更注重技术的运用
本文在itpub（）、博客园（）和个人微信公众号（）上有同步更新
本文itpub地址：
本文博客园地址：
本文pdf版及小麦苗云盘地址：
● QQ群：&&&&
微信群：私聊
联系我请加QQ好友()，注明添加缘由
19:00 在农行完成
文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解
版权所有，欢迎分享本文，转载请保留出处
...............................................................................................................................
手机长按下图识别二维码或微信客户端扫描下边的二维码来关注小麦苗的微信公众号：xiaomaimiaolhr，免费学习最实用的数据库技术。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：5422次
排名：千里之外
原创：34篇
(5)(6)(2)(1)(5)(8)(6)(1)}