如何诊断cursor pin s wait on x 系列二

如何分析诊断收集信息

1.       查看AWR 报告中high paring 和high version部分内容

具体查看这几个部分的内容:‘SQLordered by Parse Calls‘ or ‘SQL ordered by Version Count‘

SQL ordered by Parse Calls
关于这部分中的sql 解析执行是否过高,或者能否减小来。

SQL ordered by Version Count关于这部分中的high version sql ,需要找出为啥他们不能共享,可以通过 v$sql_shared_cursor  视图查找原因

2.    systemstats 和errorstack 的关注点

对于systemstats 和errorstack 时效性非常重要。需要在问题发生时刻进行dump ,否则过时采集的信息是无效的。在一个高速运行的系统中,那些holders and waiter 进程转瞬即逝。

根据AWR 的 load profile 部分内容可以初步判断出 系统 sql 解析情况:

如果看到hard parses 很多,表明系统可能没有使用绑定变量,或者有新的sql 上线。

对于high version counts  也会导致 cursor:ping S wait on X

使用V$SQL_SHARED_CURSOR可以查找出 sql 不能共享的原因

有些bug可能会导致 high version counts:

Document 1057392.8 Bug 10157392 - High version counts forSQL with binds (BIND_MISMATCH)

Document 9689310.8 Bug 9689310 - Excessive child cursors /high VERSION_COUNT / OERI:17059 due to bind mismatch

Bug 可能会导致 cursor pin s wait on x :


NB


Bug


Fixed


Description


5650841


Hang / deadlock from ANALYZE of cluster index


16191248


12.1.0.1.1, 12.1.0.2, 12.2.0.0


Hang from concurrent drop of on-commit materialized views or using DBMS_REDEFINITION


14295250


11.2.0.4, 12.1.0.1


Long parse time for large query with many nested views due to much time in epxression analysis code


14191508


11.2.0.3.8, 11.2.0.3.BP16, 11.2.0.4, 12.1.0.1


Slow row cache load due to SEG$ and INDSUBPART$ queries


14176247


11.2.0.4, 12.1.0.1


Many child cursors using Adaptive Cursor Sharing with binds (due to BIND_EQUIV_FAILURE)


18292893


12.1.0.2, 12.2.0.0


Jobs don‘t execute per schedule with a large number of PDBs


18018515


12.2.0.0


High CPU in qctHasFakeBind (can cause ‘cursor: pin S wait on X‘ waits)


16448569


11.2.0.4, 12.1.0.2, 12.2.0.0


PQ hang/deadlock possible - "cursor: pin S wait on X" waits


16400122


12.2.0.0


Spikes in library cache mutex contention for SQL using SQL Plan Baseline


15850031


11.2.0.4, 12.2.0.0


Rare instance hang: deadlock between ‘row cache lock‘ and ‘cursor: pin S wait for X‘


14469756


12.2.0.0


Partition pruning causes delay in TBL$OR$IDX$PART$NUM


14302813


11.2.0.4, 12.2.0.0


QC blocked / parse hang for parallel DML executed from remote stored procedure


14029891


11.2.0.4, 12.1.0.1


mutex deadlock having SQL baselines on recursive dictionary cursor


11927619


11.2.0.1.BP11, 11.2.0.2.BP07, 11.2.0.3, 12.1.0.1


DBMS_STATS slow on interval composite partitions


11855965


11.2.0.3, 12.1.0.1


Truncate partition takes long time doing recursive delete on MLOG$


10213073


11.2.0.2.8, 11.2.0.2.BP18, 11.2.0.3, 12.1.0.1


CREATE SYNONYM and CREATE PACKAGE may incorrectly invalidate objects


10171273


11.2.0.2.8, 11.2.0.2.BP08, 11.2.0.3, 12.1.0.1


Long parse time with non-equi subpartitioning under interval partitioning


9944129


11.2.0.1.BP12, 11.2.0.2, 12.1.0.1


SQL not shared due to INST_DRTLD_MISMATCH with global transaction


9935787


11.2.0.3, 12.1.0.1


Long parse time for large inlists - can cause ‘cursor: pin S wait on X‘ waits


9694101


10.2.0.5.7, 11.2.0.2, 12.1.0.1


Hang / deadlock between "cursor: pin S wait on X" and "library cache lock" involving dictionary objects


9499302


10.2.0.5.5, 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2, 12.1.0.1


Improve concurrent mutex request handling


9472669


11.2.0.1.BP12, 11.2.0.2, 12.1.0.1


‘cursor: pin S wait on X‘ waits for invalid SQL over DB link


8508078


11.2.0.2, 12.1.0.1


Contention from many concurrent bad SQLs - superseded


12432089


11.2.0.3


library cache lock/cursor: pin S wait on X with parallel partition stats gathering


8441239


11.2.0.1


Library cache lock waits if long running TRUNCATE in progress


8348464


11.1.0.7.2, 11.2.0.1


CREATE SYNONYM and CREATE PACKAGE may incorrectly invalidate objects


7234778


11.2.0.1


Unnecessary "cursor: pin S wait on X" waits


5485914


10.2.0.4


Mutex self deadlock on explain / trace of remote mapped SQL


6143420


10.2.0.5, 11.1.0.6


Deadlock involving "ROW CACHE LOCK" on dc_users AND "CURSOR: PIN S WAIT ON X"


6011045


10.2.0.5.5


DBMS_STATS causes deadlock between ‘cursor: pin S wait on X‘ and ‘library cache lock‘


7462072


10.2.0.4.3, 10.2.0.5


Unnecessary "cursor: pin S wait on X" waits


5983020


10.2.0.4


MMON deadlock with user session executing ALTER USER


7226463


10.2.0.5


EXECUTE IMMEDIATE no releasing mutex or library cache pin


+


5907779


10.2.0.4


Self deadlock hang on "cursor: pin S wait on X" (typically from DBMS_STATS)

时间: 2024-10-10 04:06:44

如何诊断cursor pin s wait on x 系列二的相关文章

【翻译自mos文章】找到'cursor: pin S wait on X' 等待事件的阻塞者session(即:持有者session)

找到'cursor: pin S wait on X' 等待事件的阻塞者session(即:持有者session) 来源于: How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' (Doc ID 786507.1) 适用于: Oracle Database - Enterprise Edition - Version 10.2.0.1 to 11.2.0.3 [Release 10.2 to 11.2

cursor: pin S

OTN 解释如下: cursor: pin SA session waits on this event when it wants to update a shared mutex pin and another session is currently in the process of updating a shared mutex pin for the same cursor object. This wait event should rarely be seen because a

NDMCDB数据库hang住故障分析 - cursor: pin S wait on X

问题描述: 上午刚刚到办公室,就有监控人员邮件反馈,昨晚NDMCDB407数据库被重启过,让我分析一下数据库重启的原因.由于昨晚业务有版本上线,所以短信警告关闭了,所以没有短信下发到我手机上,而且故障时相关人员也没有通知到我. 1     检查alert日志 从alert日志中,可以看到,先是在03:29时有一个job运行失败了: Fri Aug 22 03:29:29 2014 Errors in file/opt/oracle/diag/rdbms/ndmcdb/NDMCDB/trace/N

cursor: pin S wait on X数据库缓慢

应用反应说系统慢,时间不固定,现象不知道,就是慢.无奈只好登陆系统查查看了. 查看系统上现有的快照信息 SQL> col mintime for a30 SQL> col maxtime for a30 SQL> SQL> select min(snap_id) minid, max(snap_id) maxid, 2  to_char(min(begin_interval_time),'yyyy-mm-dd hh24:mi:ss') mintime, 3  to_char(max

关于cursor: pin S wait on X 和 library cache pin 及其他等待事件

cursor: pin S wait on X 也好,library cache pin 也罢,这都是shared pool 的等待事件,关于此类的等待事件,阅读的书有:<<oracle 内核技术揭秘>>,<<高级owi与oracle性能调整>> 其中,<<oracle 内核技术揭秘>> 是吕海波大师所著,吕大师也是我的OCM培训老师,在此向吕大师致敬. <<高级owi与oracle性能调整>> 是Oracle

enq: SQ – contention、cursor: pin S wait on X等事件引发的故障处理

事情已经过去一年,发生在15年1月份,某全国业务系统,实时的号码办理系统,收到短信告警,该系统断开连接.数据库出现大量enq: SQ – contention.cursor: pin S wait on X等事件,alert日志中出现大量的ORA-04031报错.进行flush share pool后进行了相关查询操作. 9点前后,活动会话数突然攀升,与alert日志在1月31号首次出现ORA-04031错误时间吻合 TO_CHAR(TRUNC(SA   COUNT(*) -----------

Cursor: pin S wait on X

What is a 'Cursor: pin S wait on X' wait? A cursor wait is associated with parsing in some form. A session may wait for this event when it is trying to get a mutex pin in Share mode but another session is holding the mutex on the same cursor in exclu

遇到cursor: pin S等待事件

背景: 主库:rac两个节点,每一个节点均是:8个逻辑cpu,16g内存 有dg备机,dg备机是单机:8个逻辑cpu,16g内存 主库rac由于存储微码升级,因此临时把db switchover到dg备机上跑了一天的业务,在备机承担业务的一天之中,v$session中有很多cursor: pin S等待事件,前台业务反馈很慢.呵呵,有时候软解析多了也不是好事. 而dg备机的配置相当于rac其中的一个节点,显然备机的容灾能力是不足的. 因此,当rac对应的存储微码升级之后,db switchove

library cache lock和cursor: pin S wait on X等待

1.现象: 客户10.2.0.4 RAC环境,出现大量的library cache lock和cursor: pin S wait on X等待,经分析是由于统计信息收集僵死导致的.数据库在8点到9点期间,数据库两个节点都存在明显的cursor: pin S wait on X和library cache lock的等待: TOP 5 EVENT: Event Waits Time(s) Avg   Wait(ms) %   Total Call Time Wait   Class cursor