怎么发现RAC环境中'library cache pin'等待事件的阻塞者(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 11.1]

Information  in this document applies to any platform.

Add ***Checked for relevance on 15-Dec-2010***

Goal

The goal of this note is to explain how to understand who is blocking a ‘library cache pin‘ in a RAC environment

Fix

a. introduction

V$SESSION blocking fields can‘t be used for library cache locks/pins.

Note:169139.1 explains how to diagnose library cache locks/pin in single instance systems. The pin/lock handles
are however different on each database instance. So, the pin/lock handle of the  DBA_KGLLOCK can‘t be used with a  RAC database and view DBA_KGLLOCK can just be used to locate waiting sessions.

Note:34579.1 can then be used to locate the object locked (via the x$kglob query) on some other instances.

Once you have the object locked, you can query  each instance and drill down the opposite way

to know who is holding a pin on that object via instance views X$KGLOB to get the local instance KGLHDADR => then v$session/DBA_KGLLOCK.

2. scenario example

Scenario to simulate a ‘library cache pin‘ problem

a. Session 1 on instance1: Create a dummy procedure:

Create or replace procedure dummy is
begin
null;
end;
/

b. Session 1 on instance1: Execute the above procedure in a PL/SQL block to block the dummy

Begin
Dummy;
Dbms_lock.sleep(1000);
End;
/

3. Session 2 on instance2: Compile the  the above procedure.

alter procedure dummy compile;

=> session 2 will be blocked in 'library cache pin'.

3. How to find the blocker

a. find the p1raw value of the ‘library cache pin‘, e.g.

select sid, event, p1raw from v$session_wait where event = 'library cache pin';
SID EVENT             P1RAW
--- ----------------- --------
150 library cache pin 288822D4
select * from dba_kgllock where kgllkreq > 0;
KGLLKUSE KGLLKHDL KGLLKMOD KGLLKREQ KGLL
-------- -------- -------- -------- ----
2CB1F978 288822D4        0        3 Pin

2. find the locked object via x$kglob, e.g.

select kglnaown, kglnaobj from x$kglob where kglhdadr = '288822D4';
KGLNAOWN KGLNAOBJ
-------- --------
SYS      DUMMY

3. find the kglhdadr in the other instances, e.g.--->这是在其他的实例上执行。

select kglhdadr, kglnaown, kglnaobj from x$kglob where kglnaobj = 'DUMMY';
KGLHDADR KGLNAOWN KGLNAOBJ
-------- -------- --------
28577AD8 SYS      DUMMY

4. find the blocking session on the remote instance, e.g.--->这是在其他的实例上执行。

select sid, serial#, sql_text from dba_kgllock w, v$session s, v$sqlarea a
where w.kgllkuse = s.saddr and w.kgllkhdl='28577AD8'
and s.sql_address = a.address
and s.sql_hash_value = a.hash_value;
SID SERIAL# SQL_TEXT
--- ------- ---------------------------------------
155    939  begin dummy; dbms_lock.sleep(1000); end;

怎么发现RAC环境中'library cache pin'等待事件的阻塞者(Blocker)?

时间: 2024-10-12 16:43:58

怎么发现RAC环境中'library cache pin'等待事件的阻塞者(Blocker)?的相关文章

Oracle 11g下重现library cache lock等待事件

从下面的例子中可以看到,在生产数据库中对象的重新编译会导致library cache lock,所以应该尽量避免在业务高峰期编译对象.如果是package或过程中存在复杂的依赖关系就极易导致library cache lock的出现,所以在应用开发的过程中,也应该注意这方面的问题. session1: SQL> select * from v$version; BANNER -------------------------------------------------------------

外键约束列没建索引导致大量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

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] ~]$

【翻译自mos文章】在11gR2 rac环境中,文件系统使用率紧张,并且lsof显示有很多oraagent_oracle.l10 (deleted)

在11gR2 rac环境中,文件系统使用率紧张,并且lsof显示有很多oraagent_oracle.l10 (deleted) 参考原文: High Space Usage and "lsof" Output Shows Many 'oraagent_oracle.l10 (deleted)' in GI environment (Doc ID 1598252.1) 适用于: Oracle Database - Enterprise Edition - Version 11.2.0.

RAC环境中threads变更后如何确保goldengate继续正常复制

RAC环境中threads变更后如何确保goldengate继续正常复制 转载:http://www.easyora.net/blog/goldengate_rac_threads_remap.html 当rac节点变更的时候,比如我们添加或者删除了集群中的节点,理所当然会对节点对应的log threads进行添加或者删除,但会造成goldengate的map log threads的顺序发生紊乱.在进行这一类行为变更的时候,特别需要注意goldengate端也需要进行特别处理. 比如,在节点添

关于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

在windows 2003 sp2 或者 2008 rac环境中,可能会由于默认的SNP( Scalable Networking Pack)特性会导致 实例驱逐或者节点驱逐

在windows 2003 sp2 或者 windows 2008 rac环境中,可能会由于默认的SNP( Scalable Networking Pack)特性会导致 实例驱逐或者节点驱逐 参考原文: RAC on Windows: Recurring Instance and/or Node Evictions May Be Caused by Default SNP Features Available for Windows Server 2003 SP2 and 2008 (Doc I

【翻译自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

RAC 性能分析 - &#39;log file sync&#39; 等待事件

简介 本文主要讨论 RAC 数据库中的'log file sync' 等待事件.RAC 数据库中的'log file sync' 等待事件要比单机数据库中的'log file sync' 等待事件复杂,主要原因是由于RAC 数据库需要将SCN同步到所有实例. 首先,回顾一下单机数据库中的'log file sync' 等待事件,当user session 提交(commit)时,user session会通知LGWR进程将redo buffer中的信息写入到redo log file,当LGWR