一. Library Cache 说明
LibraryCache 是Oracle SGA 中Shared pool 的组成部分。Shared Pool的说明，参考之前的blog：
这里重点看一下Library Cache的一个管理机制。 参考了如下2篇blog，重新进行了整理：
Librarycache内部机制详解
Oracle中执行计划的存储位置
1. DSI 中对Library Cache的说明：
（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.
2. Library Cache 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
3. Shared Cursors
（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
4. Library Cache Architecture
（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.
5. Library cache需要解决三个问题：
（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。
6. Object Handle
在上图我们可以看到Object handle 保存的信息。 Library cache handle指向library cache object(LCO, heap 0),它包含了library object的名字，命名空间，时间
戳，引用列表，lock对象以及pin对象的列表信息等等。
关于Namespace，参考我的blog：
所以对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 来保存的。
7.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.
7.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
7.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
7.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中类型。
7.4.1 dependency table
指向本对象所依赖的对象，比如：select * from emp这个cursor的对象，依赖emp这个表，这里指向了emp这个表的handle。
7.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 问题说明
7.4.3.authorization table
对象的授权信息。
7.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 结构如下图：
这里要注意的，就是我们SQL的执行计划就是存放在这个Heap 6：SQL Context 中。
二. 测试
在上面的说明中，提到，对于多child cursor，所有的child cursor 都保存在child table里，并且SQL 的执行计划也保存在child cursor的Heap 6中。 下面进行相关的测试，证明以上结论。
SYS@anqing1(rac1)> create table lct asselect * from dba_objects;
Table created.
分别用SYSTEM和Dave 用户执行如下SQL:
/* Formatted on 2011/7/24 15:07:20(QP5 v5.163.1008.3004) */
DECLARE
x VARCHAR2 (20);
str VARCHAR2 (200);
BEGIN
x := 'I_PROXY_ROLE_DATA$_1';
str := 'select* from sys.lct where object_name=:x';
EXECUTE IMMEDIATE str USING x;
END;
/
查看SQL 的version count信息
SYS@anqing1(rac1)> selectsql_id,version_count from v$sqlarea where sql_text like 'select * from sys.lctwhere %';
SQL_ID VERSION_COUNT
------------- -------------
5d8tu19t1fug2 2
--查看parentcursor 和 child cursor的handle address：
SYS@anqing1(rac1)> selectaddress,child_address from v$sql where sql_id='5d8tu19t1fug2';
ADDRESS CHILD_AD
-------- --------
30A9DCDC 2CBA64AC
30A9DCDC 2A32C000
将library cache dump出来：
SQL> alter session set events 'immediatetrace name library_cache level 11';
Session altered.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/oradata/XEZF/admin/udump/xezf_ora_14041.trc
--查看trace 文件：搜索30A9DCDC
BUCKET 92642:
LIBRARY OBJECT HANDLE:handle=30a9dcdc mtx=0x30a9dd90(2) cdp=2
--object handle 的内存地址
name=select * from sys.lct whereobject_name=:x
--object 的名称
hash=55555e74e494aa0356a33a0a721769e2 timestamp=07-24-2011 15:03:04
--hash值和timestamp
namespace=CRSRflags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
--namespace 和 flags
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0latch#=1 hpc=0006 hlc=0006
--Heaps loaded and kept,lock, pin, and latch modes
lwt=0x30a9dd38[0x30a9dd38,0x30a9dd38]ltm=0x30a9dd40[0x30a9dd40,0x30a9dd40]
pwt=0x30a9dd1c[0x30a9dd1c,0x30a9dd1c]ptm=0x30a9dd24[0x30a9dd24,0x30a9dd24]
ref=0x30a9dd58[0x30a9dd58,0x30a9dd58]lnd=0x30a9dd64[0x30a9dd64,0x30a9dd64]
--以上是：Linklists of lock waiters, temporary locks, pin waiters, temporary pins andreferences
LOCK OWNERS:
lock user session count mode flags
-------- -------- -------- ----- ---- ------------------------
2d1a0cac 30efbd20 30efbd20 2N [00]
2d10501c 30f10e78 30f10e78 2N [00]
LIBRARY OBJECT: object=2aa6cf2c
--Memory address of theobject (heap 0)
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
--Object type, flags, andstatus
CHILDREN: size=16
child# table reference handle
------ -------- --------- --------
02c08c08c 2c08bd5c 2cba64ac
1 2c08c08c 2c08bec8 2a32c000
--这个就是所有child cursor 的handle 的内存地址
DATA BLOCKS:
data# heap pointer status pins change whr
----- -------- -------- --------- ---- ------ ---
0 2b8839b4 2aa6cfc4 I/P/A/-/- 0NONE 00
--Object data structures(heap descriptors)
BUCKET 92642 total object count=1
查看其中一个child cursor 地址，在trace 里搜索：2cba64ac
LIBRARY OBJECT HANDLE: handle=2cba64acmtx=0x2cba6560(0) cdp=0
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=1 hpc=0002 hlc=0002
lwt=0x2cba6508[0x2cba6508,0x2cba6508] ltm=0x2cba6510[0x2cba6510,0x2cba6510]
pwt=0x2cba64ec[0x2cba64ec,0x2cba64ec]ptm=0x2cba64f4[0x2cba64f4,0x2cba64f4]
ref=0x2cba6528[0x2c08bd5c,0x2c08bd5c]lnd=0x2cba6534[0x2cba6534,0x2cba6534]
CHILD REFERENCES:
reference latch flags
--------- ----- -------------------
2c08bd5c 0 CHL[02]
LOCK OWNERS:
lock user session count mode flags
-------- -------- -------- ----- ---- ------------------------
2d345160 30efbd20 30efbd20 1N [00]
2d1a0bdc 30f10e78 30f10e78 1N [00]
LIBRARY OBJECT: object=2c1a3280
type=CRSR flags=EXS/RIV[0201] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=1 size=16
dependency# tablereference handle position flags
----------- -------- --------- -------- -------- -------------------
0 2db7d838 2db7d770 2bb25644 18 DEP[01]
AUTHORIZATIONS: count=1 size=16 minimum entrysize=16
00000000 30000000 00020000 00000000
ACCESSES: count=1 size=16
dependency# types
----------- -----
0 0009
SCHEMA: count=1 size=262144
0000003d
DATA BLOCKS:
data# heap pointer status pins change whr
----- -------- -------- --------- ---- ------ ---
0 2a078574 2c1a3318 I/P/A/-/- 0NONE 00
6 2aa6d2542c4f9cf0 I/-/A/-/E 0 NONE 00
这个结构和Heap 0的差不多。 但是这个child cursor 没有name了。 因为我们访问时先通过parent cursor。 在到child cursor。所以parent cursor 有name 就可以了。
这里的Data blocks 有2个： data block 0和data block 6. 对应heap 0 和heap 6. 关于Heap 0的说明如下：
The data block structure for a heap, stored in heap 0,contains a pointer to the first data block that is allocated for the heap, astatus indicator, the pin under which the heap is loaded, and so on.
执行计划保存在Heap 6里，我们把Heap 6 dump 出来，看一下：
SYS@anqing1(rac1)> alter session setevents 'immediate trace name heapdump_addr level 2,addr 0x2aa6d254';
Session altered.
--注意，这里的addr前面加了0x。
SYS@anqing1(rac1)> oradebug setmypid
Statement processed.
SYS@anqing1(rac1)> oradebugtracefile_name
/u01/app/oracle/admin/anqing/udump/anqing1_ora_1533.trc
在trace 里搜索：0x2aa6d254
HEAP DUMP heapname="sql area" desc=0x2aa6d254
extent sz=0xff4 alt=32767 het=156 rec=0 flg=2opc=2
parent=0x2000002c owner=0x2aa6d1c8 nex=(nil)xsz=0xff4
EXTENT 0 addr=0x2a73d5e8
Chunk 2a73d5f0 sz= 788 free " "
Dump of memory from 0x2A73D5F0 to0x2A73D904
2A73D5F0 C0000315 00000000 2AA6D2B42AA6D2B4 [...........*...*]
2A73D600 2B10E1FC C0000051 000000002C49E55C [...+Q.......\.I,]
2A73D610 2AEA8820 00314E00 0000800400010035 [ ..*.N1.....5...]
2A73D620 00930024 00020001 0019003A00020074 [$.......:...t...]
2A73D630 001A0019 000200BF 007400B000500004 [..........t...P.]
2A73D640 001A0024 00BF0033 0003001200010022 [$...3......."...]
2A73D650 62000006 0000024D 2A73D6040C9D040C [...bM.....s*....]
2A73D660 00000000 2A73D8A0 0035000000240001 [......s*..5...$.]
2A73D670 00010093 003A0002 0074001900190002 [......:...t.....]
2A73D680 00BF001B 00B00002 0004007400240039 [........t...9.$.]
2A73D690 0033001B 001200BF 0022000300060001 [..3.......".....]
2A73D6A0 12021400 00010022 0A000006006B0802 [....".........k.]
2A73D6B0 03671F85 EF042C04 001C004E000C0000 [..g..,..N.......]
2A73D6C0 001D0400 001C0056 000002E0001D0040 [....V.......@...]
2A73D6D0 00B10028 000D0028 008C00260026005E [(...(...&...^.&.]
2A73D6E0 00A40026 000E000C 0E00002612011201 [&.......&.......]
2A73D6F0 00010022 AC000009 00AF0A0000010021 ["...........!...]
2A73D700 00020074 00210009 001500BF00780026 [t.....!.....&.x.]
....
dbsnake blog里的总结如下：
heap6实际上就是sql area（这个和上图中描述的heap 6是sql context不尽相同）。 Oracle把sql的执行计划存在了这个sql的子cursor的heap 6（也就是sql area）中,只不过存储的形式是编译好的二进制格式。
MOS 上的相关说明：
Parsinga cursor builds four different library cache structures, if they do not alreadyexist, within the library cache:
1、parent cursor handle
2、parent cursor object, containing the child dependency list
3、child cursor handle, inserted in the child dependency list of theparent object
4、childcursor object, containing the compilation and run-time execution plan for thecompiled SQL statement.
