share pool 管理机制
Library cache是Shared pool的一部分，它几乎是Oracle内存结构中最复杂的一部分，主要存放shared curosr（SQL）和PLSQL对象（function，procedure，trigger）的信息，以及这些对象所依赖的table，index，view等对象的信息。
Library cache需要解决三个问题：
1.快速定位的问题：Library cache中对象众多，Oracle如何管理这些对象，以便服务进程可以迅速找到他们需要的信息。比如某个服务进程需要迅速定位某个SQL是否存在于Library cache中。
2.关系依赖的问题：Library cache中的对象存在复杂的依赖关系，当某个objec失效时，可以迅速将依赖其的对象也置为失效状态。比如某个表发生了结构变化，依赖其的SQL语句需要重新解析。
3.并发控制的问题：Library cache中必须有一个并发控制的机构，比如锁机制，来管理大量共享对象的并发访问和修改的问题，比如某个SQL在重新编译的同时，其所依赖的对象不能被修改。
Library cache结构：
Oracle利用hash table结构来解决library cache中快速定位的问题，hash table就是很多hash bucket组成的数组：
LibraryCache 保存了explicitSQL， PL/SQLcommands，shared 和 nonshared cursors。 这些对象都保存在Hash table里，Hash table 又由Hash Bucket组成。 Hash Bucket 由一些Object Handle List 组成，所以在Hash Bucket里查找某个对象，就是搜索这个Handle List。
Object Handle
在上图我们可以看到Object handle 保存的信息。 Library cache handle指向library cache object(LCO, heap 0),它包含了library object的名字，命名空间，时间
戳，引用列表，lock对象以及pin对象的列表信息等等。
关于Namespace，参考我的blog：
Oracle Namespace 说明
http://blog.csdn.net/tianlesoftware/article/details/6624122
所以对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也会被加载到内存中。
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 来保存的。
1 Object Types
（1）Objects aregrouped in namespaces according to their type.
（2）Each object can only be of onetype.
（3）All the objects of the same typeare in the same namespace.
（4）A namespace may be used by morethan one type.
（5）The most important namespace iscalled cursor (CRSR) and houses the shared SQL cursors.
2 Object Names
（1）Library cache object names havethree parts:
Nameof schema
Nameof object
Nameof database link (remote objects only)
（2）The format used isSCHEMA.NAME@DBLINK.
Forexample, HR.EMPLOYEES@ACME.COM
3 Object Flags
（1）Public flags:
Arenot protected by pins or latches
Indicatein detail the type of the object
（2）Status flags:
Areprotected by pins
Indicatewhether the object is being created/dropped/altered/updated
（3）Special status flags:
Areprotected by the library cache latch
Arerelated to object validity and authorization
4 Object Tables
（1）Dependency table
（2）Child table
（3）Translation table
（4）Authorization table
（5）Access table
（6）Read-only dependency table
（7）Schema name table
Object Table 又分为以上7中类型。
4.1 dependency table
指向本对象所依赖的对象，比如：select * from emp这个cursor的对象，依赖emp这个表，这里指向了emp这个表的handle。
4.2.child table
指向本对象的子对象，比如某个游标的子游标。通俗点说，就是一条SQL 至少有一个parent cursor 和 child cursor。 可能一些SQL 由于某些原因无法共享childcursor，这样就会出现一个parentcursor 和 多个child cursor的情况。 即version count 很高。 那么这种情况下。 parent cursor 里对应的所有childcursor的指针都会保存在child table里面。 Oracle 是用C 写的，所以这里是指针。
注意一点，parent cursor和child cursor都是用library cache object handle 存储在Library Cache里的。即他们的结构完全一样。
这个结论可以通过library cache的dump 文件来证明。在后面我们会做一个测试。
Oracle 高 Version counts 问题说明
http://blog.csdn.net/tianlesoftware/article/details/6628232
4.3.authorization table
对象的授权信息。
5 Object Data Blocks
（1）The remainder ofan object’s data is stored in other independent data heaps.
（2）The object structure contains anarray of data block structures.
（3）The data blockstructures have a pointer to a different data heap.
（4）An object structure has room for 16data block structures but not all of them are in use.
Heap0 也仅仅保存是一个结构，它不保存实际的data。 而实际data 的存储Heap 的指针就存放在这个Data Blocks里。 这个也可以通过dump 来查看。这个Data Blocks指向的Heap 结构如下图：
