内容如下:

今天接到同事的电话,说他的一个存储过程已经run了一个多小时了,还在继续run,他觉得极不正常,按道理说不应该run这么长时间。

我说那我去看一下吧。

这个库是一个AIX上的10.2.0.4,我采集了一下问题时间段的AWR报告:

从AWR报告结果里我们可以看出在出问题的时间段,系统在经历严重的library cache pin以及library cache lock等待。

根据Load Profile的信息,看出导致上述library cache pin和library cache lock的并不是hardparse。

对于library cache pin等待来说,AWR报告的作用有限,最有效的方式就是找到持有library cache pin以及等待library cache pin的session,然后看看他们在做什么:

SQL> SELECT s.sid, kglpnmod"Mode", kglpnreq "Req", SPID "OS Process"

2 FROM v$session_wait w, x$kglpn p,v$session s ,v$process o

3 WHERE p.kglpnuse=s.saddr

4 AND kglpnhdl=w.p1raw

5 and w.event like '%library cache pin%'

6 and s.paddr=o.addr

7 /

SID Mode Req OS Process

---------- ---------- ---------- ------------

396 0 2 6381970

396 0 2 6381970

396 0 2 6381970

396 0 2 6381970

341 2 0 4092132

341 2 0 4092132

341 2 0 4092132

341 2 0 4092132

363 0 2 3514690

363 0 2 3514690

363 0 2 3514690

363 0 2 3514690

304 0 2 3977478

304 0 2 3977478

304 0 2 3977478

304 0 2 3977478

354 0 3 3137874

354 0 3 3137874

354 0 3 3137874

354 0 3 3137874

20 rows selected

我那位run存储过程的同事所在的session是396,从上述结果里我们可以看出来396现在想以Share模式(即Req=2)去持有library cache pin,同时现在持有上述library cache pin的是session 341,且341的持有模式也是Share(即Mode=2)。

本来Share和Share是可以共享的,但不幸的是在396之前,session 354想以Exclusive模式(即Req=3)去持有上述librarycache pin,这直接导致了396需要处于等待的Queue中,同时处于Queue中的还有363和304。

我为什么这么说呢,因为oracle对library cache pin的解释中有一句非常经典的话:

An X request (3) will be blocked by anypins held S mode (2) on the object.
An S request (2) will be blocked by any X mode (3) pin held, or may queue behind some other X request.

所以从AWR报告和上述查询结果中我们可以得出如下结论:

1、 我那位run存储过程的同事为什么run了1个多小时还没有run完是因为这个存储过程正在经历严重的library cache pin等待;

2、 而为什么会导致严重的library cache pin等待是因为session 341和354联手达到了这一效果,即341以Share模式持有library cache pin,接着354想以Exclusive模式持有,这直接导致所有的后续请求全部被处于等待的Queue中。也就是说341阻塞了354,而354又间接阻塞了396。

既然知道了原因,那我们去看一下session 341在做什么事情:

SQL> selectdecode(sql_hash_value,0,prev_hash_value,sql_hash_value) from v$session wheresid=341;

DECODE(SQL_HASH_VALUE,0,PREV_H

------------------------------

784727971

间隔10秒钟后再次执行:--间隔10秒查询的目的是判断session 的内容是否改变,从而判断出session 在干什么

SQL> selectdecode(sql_hash_value,0,prev_hash_value,sql_hash_value) from v$session wheresid=341;

DECODE(SQL_HASH_VALUE,0,PREV_H

------------------------------

784727971

间隔10秒钟后再次执行:

SQL> selectdecode(sql_hash_value,0,prev_hash_value,sql_hash_value) from v$session wheresid=341;

DECODE(SQL_HASH_VALUE,0,PREV_H

------------------------------

784727971

SQL> select sql_text from v$sqltextwhere hash_value=784727971 order by piece;

SQL_TEXT

----------------------------------------------------------------

begin -- Call the procedurep_adj_rrp_main(o_vc_flag => :o_vc_flag); end;

从结果里可以看到341一直在run一个存储过程。

给持有341的那位大姐打电话,问她在做什么,她告诉我说她从昨晚就开始run这个存储过程,今早来看发现死掉了,所以她就没管了。

知道原因后处理起来还是很容易的,当我把session 341干掉后,整个系统的library cache pin一下子就降下来了,接着我那位同事的run了一个多小时的存储过程过了没多久就run完了。

一次library cache pin故障的解决过程的更多相关文章

  1. Library cache lock 故障解决一例

    今天收到同事电话,说是数据库中一张名为acct_balance进行操作是奇慢,第一反映是不是扫行计划有问题,结果我错了,现将过程记录下来. 用pl/sql连上数据库情况:1.对acct_balance ...

  2. library cache pin解决方法

    library cache pin大部分都是因为编译存储过程造成的 查找造成问题的数据库对象(一般为存储过程) SELECT * FROM v$session_wait WHERE event = ' ...

  3. 深入理解shared pool共享池之library cache的library cache pin系列三

    关于library cache相关的LATCH非常多,名称差不多,我相信一些人对这些概念还是有些晕,我之前也有些晕,希望此文可以对这些概念有个更为清晰的理解,本文主要学习library cache p ...

  4. 如何使用event 10049分析定位library cache lock and library cache pin

    Oracle Library Cache 的 lock 与 pin 说明 一. 相关的基本概念 之前整理了一篇blog,讲了Library Cache 的机制,参考: Oracle Library c ...

  5. 外键约束列并没有导致大量建筑指数library cache pin/library cache lock

    外键约束列并没有导致大量建筑指数library cache pin/library cache lock 清除一个100大数据表超过一百万线,发现已经运行了几个小时: delete B001.T_B1 ...

  6. Resolving Issues of "Library Cache Pin" or "Cursor Pin S wait on X" (Doc ID 1476663.1)

    Doc ID 1476663.1) To Bottom In this Document   Purpose   Troubleshooting Steps   Brief Definition:   ...

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

    怎么发现RAC环境中的'library cache pin'等待事件的堵塞者(Blocker) 參考自 How to Find the Blocker of the 'library cache pi ...

  8. DBA手记(学习)-library cache pin

    select sid,event,p1raw from v$session_wait where event like 'library cache pin%'; select sql_text fr ...

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

    Oracle单实例情况下的library cache pin的问题模拟与问题分析 參考自: WAITEVENT: "library cache pin" Reference Not ...

随机推荐

  1. [设计模式] 13 责任链模式 Chain of Responsibility

    转    http://blog.csdn.net/wuzhekai1985   http://www.jellythink.com/archives/878 向项目经理提交了休假申请,我的项目经理向 ...

  2. 时间序列数据库武斗大会之 KairosDB 篇

    [编者按] 刘斌,OneAPM后端研发工程师,拥有10多年编程经验,参与过大型金融.通信以及Android手机操作系的开发,熟悉Linux及后台开发技术.曾参与翻译过<第一本Docker书> ...

  3. Capsule:开源的 JVM 应用部署工具

    [编者按]本文作者 Ron Pressler 是 Parallel Universe 公司的创始人,拥有着丰富的高性能开发经验.通过这篇文章,Ron 向大家详细介绍了全新的开源 JVM 部署工具--C ...

  4. Properties --- C++读配置信息的类

    http://blog.csdn.net/billow_zhang/article/details/4304980 在开发实践中,积累了一些通用的C++ 类库,在此写出来给大家分享.也希望能给出更好的 ...

  5. C#接口的经典案例

    C#接口(interface)实例子(简单而经典)2008/12/04 10:04using System; using System.Collections.Generic; using Syste ...

  6. Mysql 1030 Got error -1 from storage engine 错误解决

    检查你的my.cnf或my.ini,里面会有一个参数innodb_force_recovery,你看看他的值,默认是没有这个参数,没有的话,他的默认值是0,这个参数的值如果大于0,innodb会被禁止 ...

  7. 李洪强漫谈iOS开发[C语言-010] - C语言简要复习

    // //  main.m //  05 - 简要复习 // //  Created by vic fan on 16/7/13. //  Copyright © 2016年 李洪强. All rig ...

  8. 李洪强iOS开发之OC语言description方法和sel

    OC语言description方法和sel 一.description方法 Description方法包括类方法和对象方法.(NSObject类所包含) (一)基本知识 -description(对象 ...

  9. 【PHPsocket编程专题(实战篇②)】兼容 Curl/Socket/Stream 的 HTTP 操作类[转]

    <?php /************************************************************ * 描述:HTTP操作类 * 作者:heiyeluren ...

  10. 【PHPsocket编程专题(理论篇)】初步理解TCP/IP、Http、Socket.md

    前言 我们平时说的最多的socket是什么呢,实际上socket是对TCP/IP协议的封装,Socket本身并不是协议,而是一个调用接口(API).那TCP/IP又是什么呢?TCP/IP是ISO/OS ...