转自：http://www.dbafree.net/?p=778
今天晚上在一个比较重要的库上，CPU严重的冲了一下，导致DB响应变慢，大量应用连接timeout，紧接着LISTENER就挂了，连接数也满了等一连串问题。
我们的监控抓取了当时系统的等待事件，ACTIVE SQL及SESSION_WAIT等待事件，所以问题比较容量定位，查看下监控，马上就发现出问题的时间点上出现大量的cusor:pin S,这个等待事件很常见。
再通过查询持有的等待事件cursor: pin S的会话正在执行的SQL语句发现仅是一条简单的SQL。通常内存中latch pin操作是相当快的，如果出现等待了，应该很可能就是该SQL执行的过于频繁。latch在Oracle中是一种低级锁，用于保护内存里的数据结构，提 供的是串行访问机制，而mutex是Oracle 10gR2引入的，也是为实现串行访问控制的功能，并替换部分latch。
在每个child cursor下面都有一个mutexes这样的简单内存结构，当有session要执行该SQL而需要pin cursor操作的时候，session只需要以shared模式set这个内存位+1，表示session获得该mutex的shared mode lock.可以有很多session同时具有这个mutex的shared mode lock；但 在同一时间，只能有一个session在操作这个mutext +1或者-1。+1 -1的操作是排它性的原子操作。如果因为session并行太多，而导致某个session在等待其他session的mutext +1/-1操作,则该session要等待cursor: pin S等待事件。
当看到系统有很多session等待cursor: pin S事件的时候，要么是CPU不够快，要么是某个SQL的并行执行次数太多了而导致在child cursor上的mutex操作争用。如果是硬件的问题，则可以升级硬件。
如果是SQL执行频率太高。最简单的做法是，将一条SQL拆分成多条SQL。增加SQL的版本数来降低并发。如一个SQL：
select name from acct where acctno=:1
可以改为如下4个SQL，则并发的争用可以下降4倍。
select /A/ name from acct where acctno=:1
select /*B*/ name from acct where acctno=:1 select /*C*/ name from acct where acctno=:1 select /*D*/ name from acct where acctno=:1cursor: pin S，cursor: pin X，cursor: pin S wait on X这三个等待事件，实际上就是替代了cursor的library cache pin，pin S代表执行（share pin），pin X代表解析（exclusive pin），pin S wait on X代表执行正在等待解析操作。这里需要强调一下，它们只是替换了访问cursor的library cache pin，而对于访问procedure这种实体对象，依然是传统的library cache pin。
参考：
http://www.hellodb.net/2010/07/oracle-library-cache.html这篇文章不错，每次看都能有所收获。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/273891.html