问题背景：
客户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发给应用研发人员进行评估并做业务逻辑调整。
