OracleLibrarycache内部机制说明

一. Library Cache 说明LibraryCache 是Oracle SGA 中Shared pool 的组成部分。Shared Pool的说明，参考这篇文章：Oracle Shared

一. Library Cache 说明

LibraryCache 是Oracle SGA 中Shared pool 的组成部分。Shared Pool的说明，参考这篇文章：

Oracle Shared pool 详解

这里重点看一下Library Cache的一个管理机制。 参考了如下2篇文章，重新进行了整理：

Librarycache内部机制详解

Oracle中执行计划的存储位置

（1）An area in the shared pool thatmanages information about:

--Sharedcursors (SQL and PL/SQL objects)

--Databaseobjects (tables, indexes, and so on)

（2）Initially created to manage PL/SQLprograms and library units, therefore called library cache

（3）Scope was extended to includeshared cursors and information about other RDBMS objects.

（1）The units of information that arestored in the library cache are called objects.

（2）There are two classes of objects:

1）Stored objects

--Created and dropped withexplicit SQL or PL/SQL commands

Examples: Tables, views, packages,functions

2）Transient objects

--Created at execution time and liveonly for the duration of the instance(or aged out)

Example: Shared and nonsharedcursors

（1）In-memory representation of anexecutable object:

SQLstatements

AnonymousPL/SQL block

PL/SQLstored procedures or functions

Javastored procedures

ObjectMethods

（2）Represented by two or more objects:

Aparent cursor that has a name

Oneor more child cursors containing the execution plan

（1）The library cache is a hash tablethat is accessible through an array of hash buckets.

（2）The library cache manager (KGL)controls the access and usage of library cache objects.

（3）Memory for the library cache isallocated from the shared pool.

（1）.快速定位的问题：Library cache中对象众多，Oracle如何管理这些对象，以便服务进程可以迅速找到他们需要的信息。比如某个服务进程需要迅速定位某个SQL是否存在于Librarycache中。

（2）.关系依赖的问题：Library cache中的对象存在复杂的依赖关系，当某个objec失效时，可以迅速将依赖其的对象也置为失效状态。比如某个表发生了结构变化，依赖其的SQL语句需要重新解析。

（3）.并发控制的问题：Library cache中必须有一个并发控制的机构，比如锁机制，来管理大量共享对象的并发访问和修改的问题，比如某个SQL在重新编译的同时，其所依赖的对象不能被修改。

Oracle利用hash table结构来解决library cache中快速定位的问题，，hash table就是很多hash bucket组成的数组。 先看DSI 405 里有几张相关的图片：

LibraryCache 保存了explicitSQL， PL/SQLcommands，shared 和 nonshared cursors。 这些对象都保存在Hash table里，Hash table 又由Hash Bucket组成。 Hash Bucket 由一些Object Handle List 组成，所以在Hash Bucket里查找某个对象，就是搜索这个Handle List。

在上图我们可以看到Object handle 保存的信息。 Library cache handle指向library cache object(LCO, heap 0),它包含了library object的名字，命名空间，时间戳，引用列表，lock对象以及pin对象的列表信息等等。

关于Namespace，参考 Oracle Namespace 说明

所以对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 cachehandle，同时object heap也会被加载到内存中。

7. Library Cache Object(LCO: Heap 0)

它的结构信息如下图。 这个图需要认真的去理解。

DSI 的说明：

（1）Internally, most of the objectidentity is represented by structures of type kglob.

（2）These are thestructures stored in heap 0.

（3）Object structures have thefollowing components:

Type

Name

Flags

Tables

Datablocks

LibraryCache 存储SQL或者shared cursors 等。 这些信息就是通过Heap 0 这个LCO 来保存的。