1.现象: 客户10.2.0.4 RAC环境,出现大量的library cache lock和cursor: pin S wait on X等待,经分析是由于统计信息收集僵死导致的.数据库在8点到9点期间,数据库两个节点都存在明显的cursor: pin S wait on X和library cache lock的等待: TOP 5 EVENT: Event Waits Time(s) Avg   Wait(ms) %   Total Call Time Wait   Class cursor…

cursor pin S wait on X: 这是10.2版本提出的mutex(互斥)机制用来解决library cache bin latch争夺问题引入的新事件,是否使用这种机制受到隐含参数_kks_use_mutex_pin的限制,从10.2.0.2开始该参 数default为true,使用这种机制oracle是为了解决library cache bin latch的串行使用问题,但是mutex貌似还不是很稳定,在很多系统中会出现cursor: pin S wait on X等待事件 ,…

declare v_sql varchar2(200); begin loop v_sql :='select seq1.nextval from dual'; execute immediate v_sql; end loop; end; SQL> select * from (select SAMPLE_TIME, SESSION_ID, NAME, P1, P2, P3 from v$active_session_history ash, v$event_name enm where as…

问题描写叙述: 上午刚刚到办公室,就有监控人员邮件反馈,昨晚NDMCDB407数据库被重新启动过,让我分析一下数据库重新启动的原因.因为昨晚业务有版本号上线,所以短信警告关闭了,所以没有短信下发到我手机上,并且故障时相关人员也没有通知到我. 1     检查alert日志 从alert日志中,能够看到,先是在03:29时有一个job执行失败了: Fri Aug 22 03:29:29 2014 Errors in file/opt/oracle/diag/rdbms/ndmcdb/NDMCDB/…

Wait Events , Posted in: Technical Track Tags: Group Blog Posts, Oracle, Technical Blog Lately, wait events %! So what exactly is the root cause? Why is so much time spent waiting on a busy mutex when it should protect just one cursor? As a troublesh…

Doc ID 1476663.1) To Bottom In this Document   Purpose   Troubleshooting Steps   Brief Definition:   Problem Confirmation:   Library Cache Pin   Cursor Pin S wait on X   Improving Performance of Library cache pin or Pin S wait on X   Measuring Succes…

[20190322]测试相同语句遇到导致cursor pin S的疑问.txt--//昨天测试遇到的情况,链接:http://blog.itpub.net/267265/viewspace-2638857/--//我一直认为打散sql语句,避开cursor: pin S等待事件,能够提高执行效率.而测试结果有点出乎意料.--//反而是测试2快于测试1,很难理解为什么会出现这样的情况,今天继续探究看看.1.环境:SCOTT@book> @ ver1PORT_STRING              …

[20190320]测试相同语句遇到导致cursor pin S的情况.txt --//前面测试链接:http://blog.itpub.net/267265/viewspace-2636342/--//各个会话执行语句相同的,很容易出现cursor: pin S等待事件.看看如果各个会话执行的语句不同.--//测试结果如何呢? -//后记:补充说明测试不严谨,请参考链接:http://blog.itpub.net/267265/viewspace-2639097/ 1.环境:SCOTT@boo…

转自:http://www.dbafree.net/?p=778 今天晚上在一个比较重要的库上,CPU严重的冲了一下,导致DB响应变慢,大量应用连接timeout,紧接着LISTENER就挂了,连接数也满了等一连串问题. 我们的监控抓取了当时系统的等待事件,ACTIVE SQL及SESSION_WAIT等待事件,所以问题比较容量定位,查看下监控,马上就发现出问题的时间点上出现大量的cusor:pin S,这个等待事件很常见. 再通过查询持有的等待事件cursor: pin S的会话正在执行的SQ…

生产库中,突然出现了大量的cursor pin s wait on x等待,第一反应是数据库出现了硬解析,查看最近的DDL语句,没有发现DDL.那么有可能这个sql是第一次进入 在OLTP高并发下产生硬解析,导致出现大量等待.但是,此次 发现等待时间很长,远远超过硬解析应该有的时间,再次分析后发现是动态采样的问题. 动态采样:在表没有统计信息或者SQL中有临时表是会发生 生产库环境:统计信息收集关闭,新建的表从来没有收集过统计信息也没有导入统计信息,并且表都很大(一百多G) 原因:因为表没有统计…