关于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 韩国公司的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)

时间： 2024-10-13 10:45:35

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

Oracle单实例情况下的library cache pin的问题模拟与问题分析

參考自: WAITEVENT: "library cache pin" Reference Note (文档 ID 34579.1) How to Find the Blocker of the 'library cache pin' in a RAC environment? (文档 ID 780514.1) 本机环境:Oracle 10.2.0.5 x86-64bit for RHEL5.8 x86-64bit 第一个session: [[email protected] ~]$

外键约束列没建索引导致大量library cache pin/library cache lock

清空一个100多万行的大表的数据,发现一直执行了几个小时: delete B001.T_B11; 通过以下SQL进行跟踪,发现经常会出现library cache pin和library cache lock的等待,怀疑有大量的recursive sql在执行,于是对这个session做了10046: 发现有大量的如下SQL执行,每删除1行T_B11,都会执行下面2条SQL一次, PARSING IN CURSOR #3 len=93 dep=2 uid=0 oct=3 lid=0 tim=14

怎么发现RAC环境中&#39;library cache pin&#39;等待事件的阻塞者（Blocker）?

怎么发现RAC环境中的'library cache pin'等待事件的阻塞者(Blocker) 参考自 How to Find the Blocker of the 'library cache pin' in a RAC environment? (文档 ID 780514.1) 本文不做翻译,全文转载: Applies to: Oracle Database - Enterprise Edition - Version 9.2.0.1 to 11.1.0.7 [Release 9.2 to

Library cache lock/pin详解

Library cache lock/pin 一.概述 ---本文是网络资料加metalink 等整理得来一个实例中的library cache包括了不同类型对象的描述,如:游标,索引,表,视图,过程,等等. 这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住. 一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)这是为了,防止其他会话也访问这个对

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

共享池之六:shared pool latch/ library cache latch /lock pin 简介

latch:library cache --desc v$librarycache; latch:library cache用于保护hash bucket.library cache lock保护HANDLE.library cache pin保护library cache object--LCO.从10G开始,library cache lock和library cache pin被MUTEX部分取代.暂时不讨论MUTEX.latch:library cache的数量:[email prote

Library Cache: Lock, Pin and Load Lock

What is "Library cache lock" ? This event controls the concurrency between clients of the library cache. It acquires a lock on the object handle so that either: One client can prevent other clients from accessing the same object. The client can

【翻译自mos文章】找到&#39;cursor: pin S wait on X&#39; 等待事件的阻塞者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等待事件

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