上一篇blog只是从概念上理解Library cache,本篇则是将Library cache从内存中dump出来,看看其结构. 基本命令 ALTER SESSION SET EVENTS 'immediate trace name LIBRARY_CACHE level LL'; 其中LL代表Level级别,对于9.2.0及以后版本,不同Level含义如下: Level =1 ,转储Library cache统计信息 Level =2 ,转储hash table概要 Level =4 ,转储L

结论 1,oradebug dump library_cache不同级别dump的library cache内容及粒度会有所区别,具体见测试开始部分2,本文测示基于oradebug dump library_cache 32,即产生最为详细的library cachem内容,进而分析library cache数据结构3,关于创建表的DDL,表,以及基于表的SQL或DML,皆会存储到不同的bucket的library object handle4,大小写不同的SQL会存储到不同的bucket的li

[20190319]shared pool latch与library cache latch的简单探究.txt --//昨天看Oracle DBA手记3:数据库性能优化与内部原理解析.pdf 电子书,看了eygle的关于latch之类的测试.--//自己也重复测试看看. --//首先说明一下11g已经不存在这个shared pool latch,改为mutexes.所以测试在10g下进行:--//注意不要在生产系统做这样的测试!! 1.环境:SCOTT@test> @ &r/ver1POR

业务系统数据库夯住,数据库内大量的library cache: mutex X及latch: shared pool等待,alert日志信息如下 Tue Sep :: WARNING: inbound connection timed out (ORA-) Tue Sep :: WARNING: inbound connection timed out (ORA-) Tue Sep :: WARNING: inbound connection timed out (ORA-) Tue Sep :

笔记:Memory Notification: Library Cache Object loaded into SGA在警告日志中发现一些这样的警告信息:Mon Nov 21 14:24:22 2011Memory Notification: Library Cache Object loaded into SGAHeap size 5800K exceeds notification threshold (2048K)Details in trace file c:\oracle\produ

原文链接:https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrlstate=23w4l35u5_4&id=1523934.1用途   提出问题,得到帮助并分享您的心得   排错步骤   什么是shared pool?   专用术语   Literal SQL   Hard Parse(硬解析)   Soft Parse(软解析)   完全相同的语句?   Sharable SQL   语句的版本   Library Cac

我们都知道可是使用 alter system flush shared_pool 来清除shared pool 信息,当时不能指定清除某个对象.因为在系统繁忙的时侯 使用 alter system flush shared_pool  是很危险的, 在oracle 10.2.0.4 以及 11g 有了新的方法.提供的DBMS_SHARED_POOL.PURGE 程序来完成. 不过需要注意一点,在10.2.0.4中,虽然PURGE过程已经存在,但是要使这个过程可以真正的生效,还必须设置一个EVEN

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

What is a 'library cache: mutex X' wait? The mutex feature is a mechanism to control access to in memory structures. It is used in a number of areas including the library cache. The library cache is a memory area that holds parsed cursor structures n

产生library cache latch原因The library cache latches protect the cached SQL statements and objects' definitions held in the library cache within the shared pool. The library cache latch must be acquired in order to add a new statement to the library cach

先来张大图: 结合上图来说明一下解析的各个步骤涉及的锁. 软解析.硬解析.软软解析区别的简单说明: 为了将用户写的sql文本转化为oracle认识的且可执行的语句,这个过程就叫做解析过程. 解析分为硬解析和软解析,SQL语句第一次解析时必须进行硬解析 一句话说明硬解析与软解析的区别是: 硬解析=需要生成执行计划   软解析=不需要生成执行计划 在Oracle中存在两种类型的SQL语句,一类为DDL语句,不共享使用,也就是每次执行都需要进行硬解析.还有一类就是DML语句,会进行硬解析或软解析. 硬

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的数量:SYS@ bys3>se

前面介绍的 shared pool,library cache结构,都是为了说明一条SQL是如何被解析的.先看下面的图: 图中涉及的各结构简单介绍 父HANDLE,里面有父游标堆0的地址.. 父游标堆0:有指向一个或多个子游标的HANDLE的句柄地址 父游标在第一次打开时被锁定,直到其他所有的session都关闭该游标后才被解锁.当父游标被锁定的时候是不能被交换出librarycache的,只有在解锁以后才能被交换出library cache.父游标被交换出内存时父游标对应的所有子游标也被交换出

Shared pool物理层面上由许多内存块(chunck)组成.从逻辑功能划分,Shared pool主要由三部分组成:Library cache,Dictionary cache和Control Structure.本文主要讲述 Library cache. Library cache library cache最主要的功能就是存放用户提交的SQL语句,SQL语句相关的解析树(解析树也就是对SQL语句中所涉及到的所有对象的展现)--->共享SQL区(shared SQL areas),私有S

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

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

内容如下: 今天接到同事的电话,说他的一个存储过程已经run了一个多小时了,还在继续run,他觉得极不正常,按道理说不应该run这么长时间. 我说那我去看一下吧. 这个库是一个AIX上的10.2.0.4,我采集了一下问题时间段的AWR报告: 从AWR报告结果里我们可以看出在出问题的时间段,系统在经历严重的library cache pin以及library cache lock等待. 根据Load Profile的信息,看出导致上述library cache pin和library cache

今天收到同事电话,说是数据库中一张名为acct_balance进行操作是奇慢,第一反映是不是扫行计划有问题,结果我错了,现将过程记录下来. 用pl/sql连上数据库情况:1.对acct_balance表的查询很慢,正常少于0.1s完成,现在要60s完成:2.使用explain plan对语句进行分析,过析比正常情况下慢很多. 下面为处理过程:1.从v$session_wait中查找有问题的waitSql>select event,count(*) from v$session_wait grou

Libraey Cache Data Access library cache是关于SQL语句的SGA中的一系列的链表, library cache是通过访问一系列的hash buckets,实现使用hash table, 每个特定的hash值,链接到SQL语句 链接到SQL语句挂载hash buckets的列表, 每个语句在特定的列表上Hashes到一个hash值 链表是一系列的处理或引用,事实上,SQL语句本身组成了句柄,在每个句柄下,可能有多个相同SQL 语句的版本,同一条SQL语句多个版

My colleague suddenly encountered a problem today,a Database becomes very slow , and the a lot of session wait library cache lock event, Let me help him to look. DB env is 10.2.0.4 rac. at first ,to generate a AWR manually. exec dbms_workload_reposit