关于等待事件cursor: pin S

2020-06-17 10:55:04 阅读：210 来源： 互联网

标签：00 01 pin ITERATOR COLLECTION cursor SQL 等待 FETCH

问题背景：
客户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 hash value: 2877633358

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

标签：00,01,pin,ITERATOR,COLLECTION,cursor,SQL,等待,FETCH
来源： https://www.cnblogs.com/shujuyr/p/13151125.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

关于等待事件cursor: pin S