2_library_cache_内存结构

内存结构示意图：

在上图我们可以看到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：表示的是库缓存对象句柄对应的库缓存对象所在的分组名。

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。
例如，
HR.EMPLOYEES@ACME.COM

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 结构

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 争用。