2_library_cache_内存结构

内存结构示意图:
2_library_cache_内存结构_第1张图片

在上图我们可以看到Object handle 保存的信息。 Library cache handle指向library cache object(LCO, heap 0),它包含了library object的名字,命名空间,时间戳,引用列表,lock对象以及pin对象的列表信息等等。所以对Library cache中所有对象的访问是通过利用library cache handle来实现的,也就是说我们想要访问library cache object,我们必须先找到library cache handle。因为Object handle保存了lock 和pin 的信息,即记录哪个用户在这个handle上有lock,或者是哪个用户正在等待获得这个lock。那么这里我们也知道了library cache lock是发生在handle上的。
当一个进程请求library cache object, librarycache manager就会应用一个hash 算法,从而得到一个hash 值,根据相应的hash值到相应的hash bucket中去寻找。如果library cache object在内存中,那么这个library cache handle就会被找到。有时候,当shared pool不够大,library cache handle会保留在内存中,然而library cache heap由于内存不足被age out,这个时候我们请求的object heap就会被重载。最坏的情况下,library cache handle在内存中没有找到,这个时候就必须分配一个新的library cache handle,同时object heap也会被加载到内存中。

Name:表示的是库缓存对象句柄所对应的库缓存对象的名称。例如,如果SQL语句对应的库缓存对象句柄,则属性Name的值就是该SQL的SQL文本;如果是表对应的库缓存对象句柄,则属性Name的值就是该表的表名。
Namespace:表示的是库缓存对象句柄对应的库缓存对象所在的分组名。
2_library_cache_内存结构_第2张图片

Heap
Object Type:Library cache object的type,包括:shared cursor、index、table、cluster、view、synonym、sequence、procedure、function、package、table body、package body、trigger等等。
Object Names:

库缓存对象名由三部分组成:
模式名

对象名

数据库链接(仅远程对象)

采用的格式为
SCHEMA.NAME@DBLINK。
例如,
[email protected]

Object Flags

Public flags:
不受引脚或锁存保护
详细说明对象
Status flags:
由引脚保护
指示对象是否正在创建/删除/更改/更新
Special status flags:
特殊状态标志
由库缓存锁保护
与对象有效性和授权有关。

Tables:记录的是与该Heap0所在的库缓存对象有关联关系的库缓存对象句柄地址的集合。
dependency table:指向本对象所依赖的对象,比如:select * from emp这个cursor的对象,依赖emp这个表,这里指向了emp这个表的handle。
child table:指向本对象的子对象,比如某个游标的子游标。子游标是指SQL文本相同,但是SQL的实际含义不同的情况,比如执行的用户不同,执行计划不同,执行的环境不同等等,我们一般称之为SQL的不同版本。一个SQL至少包含一个父游标和一个子游标。
authorization table:对象的授权信息。
Data Blocks:是一个指针,指向了data heap,即存放真实数据的地方。主要包括:diana tree,p-code,source code,shared cursor context area等等
我们SQL的执行计划就是存放在这个Heap 6:SQL Context 中。
参考出处:Library Cache 结构

2_library_cache_内存结构_第3张图片

LCO中包含众多重要的信息,其中最为关键的是以下3个信息:
1.dependency table: 当前LCO依赖的其他LCO 信息,比如 sql 语句所依赖的表、视图等。
2.child table:保存着当前LCO的子信息。
3.data blocks: 保存着SQL语句、执行计划、执行文本等信息

library cache latch:主要用于保护检索并管理library cache,sql文本经过oracle 内部的hash函数生成一个hash值,然后根据hash值检索library cache 是否存在相同的sql,在此过程中需要获得library cache latch。library cache 中的bucket 主要由library cache latch 保护。
library cache lock:handle 由 library cache lock 保护,进程在访问和修改LCO之前,必须先获得handle的library cache lock.
以下为常见的library cache lock 持有模式:
1.alter table ….:以exclusive 模式持有library cache lock
2.create or replace procedure….:以exclusive 模式持有library cache lock
3.sql 解析阶段:以shared 模式持有library cache lock
4.sql 执行阶段:将以library cache lock 从shared 模式转换为null模式。

library cache pin:进程在访问或者修改LCO之前也必须获得保护LCO的library cache pin.除此之外,library cache pin 也会保护SQL执行期间的执行计划,使其不发生更改或交换出shared pool.以下为常见:
1.alter procedure …comple:以exclusive 模式持有library cache pin
2.硬解析阶段:产生执行计划的过程中需要以exclusive 模式持有library cache pin.
3.sql执行阶段:需要以shared 模式持有library cache pin
4.procedure 执行阶段:需要以shared模式持有library cache pin.

注意:10g以后,library cache lock 和 library cache pin 逐渐被MUTEX取代。

实践证明:发生 library cache latch 争用时,并不是 library cache latch 数量不够,而是局部的library cache latch 访问比较频繁,所以设置隐含参数 _kgl_latch_count 增加latch数量 往往不能减缓library cache latch 争用。

你可能感兴趣的:(ORACLE_优化篇)