关于等待事件cursor: pin S

问题背景： 客户cpu居高不下， 1> 查看top10 sql发现大量的等待事件 SQL> / USERNAME PROGRAM      EVENT SQL_ID       CPU_TIME       SUM  CPU_USAGE --------------- -------------------- ----------------------------------- -------------------------- ---------- ---------- ---------- ECOLOGY      latch: cache buffers chains 33hkpmf3gpvd2   2734 34.6 ECOLOGY      cursor: pin S 33hkpmf3gpvd2   1384 17.5 ECOLOGY      cursor: pin S 4g6a658qd8qcf                936 1 存在latch: cache buffers chains和cursor: pin S等待， 2> 查看问题sql的sql_id SQL> select * from table(dbms_xplan.display_awr('33hkpmf3gpvd2')); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- SQL_ID 33hkpmf3gpvd2 -------------------- PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 287763335 -------------------------------------------------------------------------------------------------------------------- | Id  | Operation     | Name    | Rows  | Bytes | Cost (%CPU)| Time    | -------------------------------------------------------------------------------------------------------------------- |   0 | SELECT STATEMENT     |    |    |    | 2 (100)|    | |   1 |  SORT AGGREGATE     |    | 1 | 42 | |    | |   2 |   FILTER     |    |    |    | |    | |   3 |    TABLE ACCESS BY INDEX ROWID     | DIRACCESSCONTROLDETAIL    | 1 | 42 | 2   (0)| 00:00:01 | |   4 |     INDEX RANGE SCAN     | IX_DIRACCESSCONTROLDETAIL_SL | 1 |    | 1   (0)| 00:00:01 | PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |   5 |    COLLECTION ITERATOR PICKLER FETCH| SPLITSTR    | 1 | 2 | 2   (0)| 00:00:01 | |   6 |    COLLECTION ITERATOR PICKLER FETCH| SPLITSTR    | 1 | 2 | 2   (0)| 00:00:01 | |   7 |    COLLECTION ITERATOR PICKLER FETCH| SPLITSTR    | 1 | 2 | 2   (0)| 00:00:01 | |   8 |    COLLECTION ITERATOR PICKLER FETCH| SPLITSTR    | 1 | 2 | 2   (0)| 00:00:01 | |   9 |    COLLECTION ITERATOR PICKLER FETCH| SPLITSTR    | 1 | 2 | 2   (0)| 00:00:01 | |  10 |    COLLECTION ITERATOR PICKLER FETCH| SPLITSTR    | 1 | 2 | 2   (0)| 00:00:01 | |  11 |    COLLECTION ITERATOR PICKLER FETCH| SPLITSTR    | 1 | 2 | 2   (0)| 00:00:01 | -------------------------------------------------------------------------------------------------------------------- 42 rows selected. 从执行计划来看，出现了一个操作是COLLECTION ITERATOR PICKLER FETCH，查看了下，是对一个集合对象中的成员进行迭代取值，是比较糟糕的一种实现。 3> 查看问题时间段的awr报告， 解析和硬解析次数很高，从sql本身来看已经采用了绑定变量   这两个sql在两个小时的时间里执行了五亿次，执行次数太高了 问题解决： 超高的Cursor: Pin S等待，频繁的执行SQL共享解析时产生的竞争。由此就产生了 cursor : pin S 的等待。 这通常是由于某些SQL以超高频繁的频率执行导致的，当然也可能与系统的CPU能力不足有关。 最重要的可以清楚的看到，在过去的两个个小时内，有两个sql执行高达2亿5千万余次，系统出现大量cursor: pin S等待事件，个人感觉Oracle已经很给面子了 该SQL语句与文章开头给出的SQL是同一条语句，已经将该SQL发给应用研发人员进行评估并做业务逻辑调整。