关于等待事件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: 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报告,
关于等待事件cursor: pin S
解析和硬解析次数很高,从sql本身来看已经采用了绑定变量
关于等待事件cursor: pin S
这两个sql在两个小时的时间里执行了五亿次,执行次数太高了

问题解决:
超高的Cursor: Pin S等待,频繁的执行SQL共享解析时产生的竞争。由此就产生了 cursor : pin S 的等待。
这通常是由于某些SQL以超高频繁的频率执行导致的,当然也可能与系统的CPU能力不足有关。
最重要的可以清楚的看到,在过去的两个个小时内,有两个sql执行高达2亿5千万余次,系统出现大量cursor: pin S等待事件,个人感觉Oracle已经很给面子了
该SQL语句与文章开头给出的SQL是同一条语句,已经将该SQL发给应用研发人员进行评估并做业务逻辑调整。

 

上一篇:tp5渲染模板


下一篇:2020年下半年1+X Web前端开发(中级)理论考试模拟试题一(附答案)