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

最新推荐文章于 2025-09-12 05:30:00 发布
原创 最新推荐文章于 2025-09-12 05:30:00 发布 · 2.1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#cursor pin S wait on #library cache pin

本文探讨了Oracle数据库中共享池引发的等待事件，如cursor:pinSwaitonX及librarycachepin等问题，并推荐了两本深入研究Oracle内部机制与性能调优的专业书籍。此外，还列举了几篇官方支持文档(MOS)来帮助读者更好地理解和解决这些等待事件。

cursor: pin S wait on X 也好，library cache pin 也罢，这都是shared pool 的等待事件，关于此类的等待事件，阅读的书有：<<oracle 内核技术揭秘>>，<<高级owi与oracle性能调整>>

其中，<<oracle 内核技术揭秘>> 是吕海波大师所著，吕大师也是我的OCM培训老师，在此向吕大师致敬。

<<高级owi与oracle性能调整>> 是Oracle 韩国公司的supporter 赵东郁 所著，目前，该书只能从taobao之类的网址购买到复印版，原因是此书出版日期较早（2007年出版的）。不过此书枯荣长老居然有原版，可见枯荣长老玩oracle 之早。

 

需要阅读MOS文章有：

WAITEVENT: "cursor: pin S wait on X" Reference Note (Doc ID 1298015.1)

How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' (Doc ID 786507.1)

Troubleshooting 'cursor: pin S wait on X' waits. (Doc ID 1349387.1)


 

模拟cursor pin S wait on X
zhaoyangjian724的专栏
07-06 749
模拟cursor pin S wait on X create table test tablespace users as select *from dba_objects; BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname => 'TEST', tabname
统计信息搜集加SQL硬编码导致library cache lock 和cursor pin wait on x
zhaoyangjian724的专栏
12-15 505
分析库缓存锁问题
MRX001的博客
07-20 1163
另外一种是找到了匹配的父游标但未找到匹配的子游标，此时Oracle也会从头开始解析该目标SQL，新生成一个子游标，并把这个子游标挂在对应的父游标下。通过AWR，ASH报告，定位到SQL，找到代码，发现调用这个SQL特别频繁，而且数据量巨大，虽然通过SQL的执行计划看到SQL都走了索引，代码中看到SQL语句有一部分不是通过?软解析是指Oracle在执行目标SQL时，在Library Cache中找到了匹配的父游标和子游标，并将存储在子游标中的解析树和执行计划直接拿过来重用而无须从头开始解析的过程。
Oracle DBA实战：模拟硬解析风暴与游标争用，手动产生双等待事件（Latch: Shared Pool + Cursor: Pin S Wait On X） 附脚本
Jackyimi的博客
09-12 1029
本文手把手教你如何在Oracle 11G单机环境中，通过SQL*Plus多会话并发，精准复现“latch: shared pool”和“cursor: pin S wait on X”两大高并发等待事件！从原理剖析到可执行脚本，揭秘硬解析与游标争用的内在关联，助力DBA深度性能调优！
cursor: pin S
clc1511的博客
05-07 180
OTN的解释, cursor: pin SA session waits on this event when it wants to update a shared mutex pin and another sessi...
等待事件latch free、Cursor:pin S wait on X、Library cachelock导致数据库卡顿
m0_37625564的博客
12-03 465
数据库等待事件分析 进入数据库中查询得到数据库中存在大量的latch free、Cursor:pin S wait on X、Library cachelock等待事件和资源征用 EVENT ---------------------------------------------------------------- Latch free … Cursor:pin S wait on X … Library cache lock … AWR报告信息分析 由上图得知，在09:00~10:00，节.
oracle等待事件之cursor：pin S wait on X
conghe6716的博客
06-23 1220
cursor：pin S wait on X 什么是cursor：pin S wait on X 等待事件？ 当一个会话尝试得到一个mutex pin的时候，但是其他会话正在以exc...
library cache lock和cursor: pin S wait on X等待
cpda53349199的博客
04-27 787
　1.现象: 客户10.2.0.4 RAC环境，出现大量的library cache lock和cursor: pin S wait on X等待，经分析是由于统计信息收集僵死导致的。 数据库在8点到9点期间...
常见问题：‘cursor:mutex ..‘/ ‘cursor:pin ..‘/ ‘library cache:mutex ..‘类型的等待事件
Lixora's DB Home
01-16 1243
处理或访问cursor的任何操作都可能需要等待，才能访问在 shared pool 中支持这些操作的结构。请注意，所有这些等待事件都非常相似，并且可能都是在一个操作过程中产生的等待。Share(共享)操作可以在不更改的情况下进行，只是需要在更改过程中暂时锁定这些操作，以防止其被其他项更改。基于这些事件的争用通常是另一个问题的症状表现 – 即问题是其它地方产生的，而不是 mutex 机制本身。通常，通过采用合理的cursor共享策略，正确使用绑定变量并确保没有大量版本，应该能够避免大多数这类性质的问题。
Oracle11.2.0.4查询表一直卡住cursor:pin s on x
关注系统性能调优
09-29 1490
现场反馈:查询一张几千条数据的表，一直卡住，然后重启了数据库，还是这样。 1.获取了数据库报告，发现排在第一位的是cursor:pin s on x等待事件。 Top 10 Foreground Events by Total Wait Time Event Waits Total Wait Time (sec) Wait Avg(ms) % DB time Wait Class cursor: ...
oracle cursor: pin s wait on x （一）
热门推荐
Rhys learn oracle！
11-11 1万+
cursor: pin s on x:   今天是2013-11-11，传说中的光棍节，呵呵。之前数据库出现过一次cursor：pin s on x等待事件，距上次出现该问题已经有10天了，但是一直也懒的去总结这个事件，今天就深入研究一下： 第一：什么是cursor:pin s on x? A session waits for this event when it is request
cursor: pin S wait on X等待事件。
cotchte0421的博客
12-05 189
select * from v$version;BANNER------------------------------------------------------------------------------------...
oracle游标等待,oracle等待事件之cursor：pin S wait on X
weixin_36091052的博客
04-08 594
cursor：pin S wait on X什么是cursor：pin S wait on X 等待事件？当一个会话尝试得到一个mutex pin的时候，但是其他会话正在以exclusive模式持有相同cursor object的mutex，此时申请mutex pin的会话等待事件即为cursor：pin S wait on X 。造成该等待事件的原因：1.shared pool设置太小，或者由于...
cursor pin S wait on X
weixin_30596343的博客
03-22 352
cursor pin S wait on X； 这是10.2版本提出的mutex(互斥)机制用来解决library cache bin latch争夺问题引入的新事件,是否使用这种机制受到隐含参数_kks_use_mutex_pin的限制,从10.2.0.2开始该参 数default为true,使用这种机制oracle是为了解决library cache bin latch的串行使用问题...
cursor: pin S wait on X等待事件
weixin_34006965的博客
03-19 141
A session waits on this event when requesting a mutex for sharable operations related to pins (such as executing a cursor), but the mutex cannot be granted because it is being held exclusively by anot...
oracle游标等待,cursor: pin S wait on X 等待事件
weixin_36071315的博客
04-08 443
cursor: pin S整体描述cursor: pin S A session waits on this event when it wants to update a shared mutex pin and another sessionis currently in the process of updating a shared mutex pin for the same curso...
Oralce共享池管理-cursor: pin s wait on x
oradbm的博客
09-24 327
cursor: pin s wait on x A session waits for this event when it is requesting a shared mutex pin and another session is holding an exclusive mutex pin on the same cursor objec（注意在10G之后library cache pin 被mutex取代） 说当一个会话请求共享mutex pin的时候，另一个会话正好在同一个游标对象上持有排他pi
cursor: pin S wait on X等待事件的处理过程
m0_38048955的博客
01-11 2244
如何解决
cursor: pin S wait on X 1 610.6 610565.35 17.7 Concurrency什么问题
最新发布
11-26
<think> 我们正在讨论Oracle数据库中的等待事件"cursor: pin S wait on X"。根据用户提供的字符串，它包含以下关键信息： cursor: pin S wait on X 1 610.6 610565.35 17.7 Concurrency 这个等待事件通常发生在并发环境中，当一个会话试图以共享模式（S）获取一个游标，而另一个会话正以独占模式（X）持有该游标，或者正在等待获取独占模式时。 具体分析： 1. 事件名称：cursor: pin S wait on X 2. 参数解读（根据Oracle文档，该等待事件有4个参数）： - p1: 被请求的游标的句柄地址（即想要以共享模式获取的游标） - p2: 阻塞游标的句柄地址（即当前以独占模式持有的游标） - p3: 被请求的游标的引用地址（可能用于跟踪） - p4: 阻塞游标的引用地址（可能用于跟踪） 但是用户提供的数据中，在事件名称后有5个数值：1, 610.6, 610565.35, 17.7, Concurrency。这里需要调整理解，通常等待事件的参数是4个，最后一个"Concurrency"可能是额外的描述。 然而，标准参数应该是4个，所以我们可以这样理解： p1: 1 （可能是被请求游标的句柄地址，但通常地址是十六进制，这里显示为整数，可能是转换后的） p2: 610.6 -> 这个数值看起来不太像地址，可能是数值型ID或转换后的值 p3: 610565.35 p4: 17.7 这种数值的表示方式可能是由于工具显示的问题。通常，在AWR或ASH报告中，这些参数会以十六进制或十进制的形式显示，但这里出现了小数，这不太常见。可能这些数字是经过转换的，或者包含了时间等信息。 不过，我们关注的重点是等待事件本身的原因和解决方法。 原因： 该等待事件通常是由于并发执行同一个SQL语句（或PL/SQL对象）时，多个会话同时尝试解析（parse）该语句导致的。Oracle为了管理游标的共享，使用了游标引脚（pin）机制。当一个会话需要修改游标（例如，硬解析或重新优化）时，它会请求一个独占引脚（X pin），而其他会话如果同时需要执行该游标，则会请求共享引脚（S pin）。如果已经有会话持有或正在等待独占引脚，那么请求共享引脚的会话就会等待"cursor: pin S wait on X"事件。 可能的原因包括： 1. 高并发硬解析：当多个会话同时硬解析同一个SQL语句时，会导致竞争。 2. 游标失效：如果游标失效（例如由于统计信息更新、对象变更等），多个会话同时尝试重新解析该游标。 3. 频繁执行DDL：DDL操作会导致相关游标失效，从而引发重新解析。 4. 绑定变量窥视（Bind Peeking）或自适应游标共享（ACS）导致游标版本过多，增加了管理负担。 5. 游标未共享：由于没有使用绑定变量，导致游标数量过多，也可能间接导致游标管理开销增加。 解决方法： 1. 优化应用使用绑定变量，减少硬解析。 2. 避免在高峰时段执行DDL操作。 3. 调整游标共享参数（如cursor_sharing），但需谨慎。 4. 增加共享池大小（shared_pool_size）可能有一定帮助，但这不是根本解决方法。 5. 检查是否有频繁失效的游标（通过监控v$sqlarea中的invalidations列）。 6. 使用SQL补丁（SQL Patch）或SQL计划基线（SQL Plan Baseline）来稳定执行计划，减少重新解析。 另外，从用户提供的数值中，我们看到等待时间17.7（可能是17.7毫秒？），但通常等待事件的时间单位是毫秒。而前面的数值610.6和610565.35等，可能是等待事件相关的对象标识，具体需要结合当时的环境分析。 由于该等待事件与并发解析有关，因此在高并发环境下尤其需要注意。 引用说明： [^1]: 该等待事件的解释参考了Oracle官方文档以及MOS（My Oracle Support）的相关文章，如Document ID 1310764.1等。 §§相关问题§§ 1. 如何监控数据库中的"cursor: pin S wait on X"等待事件？ 2. 除了绑定变量，还有哪些方法可以减少硬解析？ 3. 什么是游标（cursor）在Oracle中的具体含义？ 4. 如何确定是由于哪个具体的SQL语句引起的"cursor: pin S wait on X"等待事件？ </think> ### "cursor: pin S wait on X" 等待事件分析 该等待事件是 Oracle 数据库中的一种并发控制机制，主要发生在多个会话同时访问同一游标时。具体分析如下： #### 原因解析 1. **并发游标访问冲突** 当会话 A 尝试以 **共享模式（S）** 获取游标时，会话 B 正持有该游标的 **独占模式（X）** 锁（或正在等待获取 X 锁），导致会话 A 阻塞并出现此等待事件[^1]。常见场景： - 高并发环境下多个会话同时解析/执行同一 SQL - PL/SQL 对象（如存储过程）被频繁并发调用 - 游标失效（cursor invalidation）后大量会话尝试重新解析 2. **共享池（Shared Pool）压力** - 共享池过小或存在内存碎片 - 未使用绑定变量导致大量相似 SQL 硬解析 - 频繁 DDL 操作引起游标失效 3. **参数配置问题** `_kks_use_mutex_pin` 参数启用时（默认 true），Oracle 使用更细粒度的互斥锁机制，可能增加此类等待概率[^2]。 #### 诊断方法 通过以下 SQL 定位阻塞源： ```sql SELECT sid, sql_id, event, blocking_session FROM v$session WHERE event = 'cursor: pin S wait on X'; ``` #### 解决方案 1. **优化应用层** - 使用绑定变量减少硬解析 - 避免高峰时段执行 DDL - 优化 PL/SQL 代码逻辑，减少重复解析 2. **调整数据库配置** ```sql ALTER SYSTEM SET cursor_sharing = FORCE; -- 强制共享相似 SQL ALTER SYSTEM SET "_kks_use_mutex_pin"=FALSE; -- 谨慎使用 ``` 3. **共享池优化** - 适当增加 `shared_pool_size` - 定期刷新共享池（应急措施）： ```sql ALTER SYSTEM FLUSH SHARED_POOL; ``` 4. **SQL 调优** 对高频 SQL 使用 SQL 计划基线稳定执行计划： ```sql DECLARE clob_var CLOB; BEGIN clob_var := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(sql_id => 'g4p8z3s7w6k2d'); END; ``` > **注意**：持续出现此等待通常表明应用存在并发设计问题，需从根本上优化代码逻辑[^2]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值