结论
1,oradebug dump library_cache不同级别dump的library cache内容及粒度会有所区别，具体见测试开始部分
2,本文测示基于oradebug dump library_cache 32，即产生最为详细的library cachem内容，进而分析library cache数据结构
3,关于创建表的DDL,表，以及基于表的SQL或DML，皆会存储到不同的bucket的library object handle
4,大小写不同的SQL会存储到不同的bucket的library object handle
5,而基于不同用户的相同SQL，会存储到同一个bucket的library object handle
不过在library object handle的结构
CHILDREN: size=16
child# table reference handle
------ -------- --------- --------
0 9da2a040 9da14758 a3552c48 ---同下，这个就是sql的多个子游标，即VERSION_COUNT
1 9da2a040 9d9cf240 a3541fc0 ---这个就是上述基于用户TEST生成的子游标,handle又会指向ANONYMOUS LIST: 中的对应的bucket
进而真正指向
对应不同的 ANONYMOUS LIST: 中的对应的不同的library object handle，所以你从这儿就可以想想，如果一个SQL的子游标过多，它就会花费更多的时间去扫描这些数据结构，哪消耗的LATCH或MUTEX就会更严重
ANONYMOUS LIST:
LIBRARY OBJECT HANDLE: handle=a3552c48 mtx=0xa3552d78(0) lct=2 pct=3 cdp=0 --即对应child#=0的上述子游标的SQL
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=6 hpc=fffe hlc=fffe
lwt=0xa3552cf0[0xa3552cf0,0xa3552cf0] ltm=0xa3552d00[0xa3552d00,0xa3552d00]
pwt=0xa3552cb8[0xa3552cb8,0xa3552cb8] ptm=0xa3552cc8[0xa3552cc8,0xa3552cc8]
ref=0xa3552d20[0x9da14758,0x9da14758] lnd=0xa3552d38[0xa3552d38,0xa3552d38]
CHILD REFERENCES:
reference latch flags
--------- ----- -------------------
9da14758 5 CHL[02]
LIBRARY OBJECT: object=9da13ff0
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=2 size=16 --可见dependencies table结构仅会在ANONYMOUS LIST: 的library object handle中出现
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 9da13ab8 9da137f8 a355af28 16 DEP[01]
1 9da13ab8 9da138f8 a3552868 0 DEP[01]
ACCESSES: count=1 size=16
dependency# types
----------- -----
0 0009
TRANSLATIONS: count=1 size=16
original final
-------- --------
a355af28 a355af28
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a3552b88 9da14108 I/-/A/-/- 0 NONE 00 2.99 3.12
6 9da14528 9bb9f1d8 I/-/A/-/E 0 NONE 00 5.51 7.90
6， 通过反向思维，可见如下的bucket对应ANONYMOUS LIST:的LIBRARY OBJECT HANDLE中的dependencies table
这里存储的是SQL的基表，即dependencies table结构存储SQL的基表
BUCKET 6797:
LIBRARY OBJECT HANDLE: handle=a355af28 mtx=0xa355b058(0) lct=5 pct=5 cdp=0
name=SCOTT.T_LIBRARYCACHE_TEST
hash=05c45c99776e0d8b6ac751c65d6a1a8d timestamp=11-23-2015 12:13:49
namespace=TABL flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-0701-0201 lock=N pin=0 latch#=1 hpc=0004 hlc=0004
lwt=0xa355afd0[0xa355afd0,0xa355afd0] ltm=0xa355afe0[0xa355afe0,0xa355afe0]
pwt=0xa355af98[0xa355af98,0xa355af98] ptm=0xa355afa8[0xa355afa8,0xa355afa8]
ref=0xa355b000[0xa355b000,0xa355b000] lnd=0xa355b018[0xa056f858,0xa3561368]
DEPENDENCY REFERENCES:
reference latch flags
--------- ----- -------------------
9da05028 7 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
9da137f8 5 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
9da03618 1 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
9d9c3340 1 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
LOCK OWNERS:
lock user session count mode flags
-------- -------- -------- ----- ---- ------------------------
9eb68b78 a4726cc0 a4726cc0 0 N [4044]
LIBRARY OBJECT: object=9da24a60
type=TABL flags=EXS/LOC[0005] pflags=[0000] status=VALD load=0
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a355ae68 9da24bb8 I/-/A/-/- 0 NONE 00 0.43 1.09
8 9da1baf0 9bb7be98 I/-/A/-/- 0 NONE 00 0.84 1.09
BUCKET 6797 total object count=1
真白说就是dependency table存储SQL的基表信息
7，可见authorization table结构仅存在于ANONYMOUS LIST中的library object handle
ANONYMOUS LIST:
LIBRARY OBJECT HANDLE: handle=a354e960 mtx=0xa354ea90(0) lct=4 pct=22 cdp=0
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=11 hpc=fffa hlc=fffa
lwt=0xa354ea08[0xa354ea08,0xa354ea08] ltm=0xa354ea18[0xa354ea18,0xa354ea18]
pwt=0xa354e9d0[0xa354e9d0,0xa354e9d0] ptm=0xa354e9e0[0xa354e9e0,0xa354e9e0]
ref=0xa354ea38[0x9da0a3a8,0x9da0a3a8] lnd=0xa354ea50[0xa354ea50,0xa354ea50]
CHILD REFERENCES:
reference latch flags
--------- ----- -------------------
9da0a3a8 0 CHL[02]
LIBRARY OBJECT: object=9da09c40
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=1 size=16
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 9da09708 9da09448 a39b2420 18 DEP[01]
AUTHORIZATIONS: count=1 size=16 minimum entrysize=18
0000 00000000 00004000 00000000 00000000
ACCESSES: count=1 size=16
dependency# types
----------- -----
0 0006
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a354e8a0 9da09d58 I/-/A/-/- 0 NONE 00 3.63 4.16
6 9da0a178 9bb516e0 I/-/A/-/E 0 NONE 00 20.03 23.74
直白的说就是：存储SQL查询相关的授权信息，当然这块内容我的理解还不够，还要研究
8，可见SQL的子游标信息是存储在ANONYMOUS LIST:中，而其没有bucket的概念，仅有library object handle的概念
9，关于lco的数据结构data block还没有研究，下文进行测试
测试
----基于之前的文章：oracle library cache之trace小记，了解下DUMP LIBRARY CACHE的命令区别
http://blog.itpub.net/9240380/viewspace-759136/
如下命令含义：
ALTER SESSION SET EVENTS 'immediate trace name LIBRARY_CACHE level LL';(也适用于oradebug dump library_cache，只是2种命令形式)
其中LL代表Level级别,对于9.2.0及以后版本,不同Level含义如下:
Level =1 ,转储Library cache统计信息
Level =2 ,转储hash table概要
Level =4 ,转储Library cache对象，只包含基本信息
Level =8 ,转储Library cache对象，包含详细信息(包括child references,pin waiters等)
Level =16,增加heap sizes信息
Level =32,增加heap信息
---为了针对性分析library cache的结构，生成测试用例
SQL> show user
USER is "SCOTT"
SQL> create table t_librarycache_test(a int,b int);
Table created.
SQL> select a,b from t_librarycache_test;
no rows selected
---转储LIBRARY_CACHE
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump library_cache 32
Statement processed.
SQL> oradebug tracefile_name
/home/ora10g/admin/ora10g/udump/ora10g_ora_12595.trc
----这就是上述测试示例中查询SQL对应的bucket
BUCKET 103856:
LIBRARY OBJECT HANDLE: handle=a3552e78 mtx=0xa3552fa8(1) lct=1 pct=1 cdp=1
name=select a,b from t_librarycache_test
hash=af65d142f6d90c766be1ab2d410795b0 timestamp=11-23-2015 12:14:05
namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=6 hpc=0002 hlc=0002
lwt=0xa3552f20[0xa3552f20,0xa3552f20] ltm=0xa3552f30[0xa3552f30,0xa3552f30]
pwt=0xa3552ee8[0xa3552ee8,0xa3552ee8] ptm=0xa3552ef8[0xa3552ef8,0xa3552ef8]
ref=0xa3552f50[0xa3552f50,0xa3552f50] lnd=0xa3552f68[0xa3552f68,0xa3552f68]
LOCK OWNERS:
lock user session count mode flags
-------- -------- -------- ----- ---- ------------------------
9ebce080 a4726cc0 a4726cc0 1 N [00]
LIBRARY OBJECT: object=9da2a140
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
------ -------- --------- --------
0 9da2a040 9da14758 a3552c48
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a3552db8 9da2a258 I/P/A/-/- 0 NONE 00 1.59 2.17
BUCKET 103856 total object count=1
---可见与测试示例中查询SQL所依赖的表也对应一个BUCKET
BUCKET 6797:
LIBRARY OBJECT HANDLE: handle=a355af28 mtx=0xa355b058(0) lct=2 pct=2 cdp=0
name=SCOTT.T_LIBRARYCACHE_TEST
略
BUCKET 6797 total object count=1
---同上，可见相关表的DDL及DML及基表皆会归属到不同的BUCKET中
BUCKET 92409:
LIBRARY OBJECT HANDLE: handle=a3560e98 mtx=0xa3560fc8(1) lct=1 pct=1 cdp=0
name=create table t_librarycache_test(a int,b int)
略
BUCKET 92409 total object count=1
----继续测试用例
SQL> select a,b from t_librarycache_test where rownum<1;
no rows selected
SQL> select a,b from t_librarycache_test where rownum<2;
no rows selected
可见上述2个测试SQL示例，是会对应2个不同的BUCKET中的LIBRARY OBJECT HANDLE
BUCKET 48737:
LIBRARY OBJECT HANDLE: handle=a35c5208 mtx=0xa35c5338(1) lct=1 pct=1 cdp=1
name=select a,b from t_librarycache_test where rownum<1
BUCKET 94348:
LIBRARY OBJECT HANDLE: handle=a357b328 mtx=0xa357b458(1) lct=1 pct=1 cdp=1
name=select a,b from t_librarycache_test where rownum<2
---继续测试，在新的用户创建上述相同的测试用例（即相同表且相同查询SQL）
SQL> conn test/system
Connected.
SQL> create table t_librarycache_test(a int,b int);
Table created.
SQL> select a,b from t_librarycache_test;
no rows selected
可见如果基于不同用户但查询SQL相同，会生成多少子游标的SQL
BUCKET 103856:
LIBRARY OBJECT HANDLE: handle=a3552e78 mtx=0xa3552fa8(2) lct=2 pct=1 cdp=2
name=select a,b from t_librarycache_test
hash=af65d142f6d90c766be1ab2d410795b0 timestamp=11-23-2015 12:14:05
namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=6 hpc=0000 hlc=0000
lwt=0xa3552f20[0xa3552f20,0xa3552f20] ltm=0xa3552f30[0xa3552f30,0xa3552f30]
pwt=0xa3552ee8[0xa3552ee8,0xa3552ee8] ptm=0xa3552ef8[0xa3552ef8,0xa3552ef8]
ref=0xa3552f50[0xa3552f50,0xa3552f50] lnd=0xa3552f68[0xa3552f68,0xa3552f68]
LIBRARY OBJECT: object=9da2a140
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
------ -------- --------- --------
0 9da2a040 9da14758 a3552c48 ---同下，这个就是sql的多个子游标，即VERSION_COUNT
1 9da2a040 9d9cf240 a3541fc0 ---这个就是上述基于用户TEST生成的子游标,handle又会指向ANONYMOUS LIST: 中的对应的bucket
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a3552db8 9da2a258 I/P/A/-/- 0 NONE 00 1.59 2.17
BUCKET 103856 total object count=1
--继续测试，相同SQL，但大小写不同
SQL> select a,b from t_librarycache_TEST;
no rows selected
可见相同SQL，但大小写相同，仍会创建新的BUCKET及所属的library object handle
BUCKET 72150:
LIBRARY OBJECT HANDLE: handle=a3546fa0 mtx=0xa35470d0(1) lct=1 pct=1 cdp=1
name=select a,b from t_librarycache_TEST
hash=d1d69941caf41b2804ac6df2538519d6 timestamp=11-23-2015 12:47:40
namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=10 hpc=0002 hlc=0002
lwt=0xa3547048[0xa3547048,0xa3547048] ltm=0xa3547058[0xa3547058,0xa3547058]
pwt=0xa3547010[0xa3547010,0xa3547010] ptm=0xa3547020[0xa3547020,0xa3547020]
ref=0xa3547078[0xa3547078,0xa3547078] lnd=0xa3547090[0xa3547090,0xa3547090]
LOCK OWNERS:
lock user session count mode flags
-------- -------- -------- ----- ---- ------------------------
9ebce080 a4726cc0 a4726cc0 1 N [00]
LIBRARY OBJECT: object=9d9c4840
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
------ -------- --------- --------
0 9d9c4740 9d9c42a0 a3546d60
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a3546ee0 9d9c4958 I/P/A/-/- 0 NONE 00 1.59 2.17
BUCKET 72150 total object count=1
由下可见相同SQL的不同子游标存储到ANONYMOUS LIST的不同的library object handle
ANONYMOUS LIST:
LIBRARY OBJECT HANDLE: handle=a3552c48 mtx=0xa3552d78(0) lct=2 pct=3 cdp=0 --即对应child#=0的上述子游标的SQL
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=6 hpc=fffe hlc=fffe
lwt=0xa3552cf0[0xa3552cf0,0xa3552cf0] ltm=0xa3552d00[0xa3552d00,0xa3552d00]
pwt=0xa3552cb8[0xa3552cb8,0xa3552cb8] ptm=0xa3552cc8[0xa3552cc8,0xa3552cc8]
ref=0xa3552d20[0x9da14758,0x9da14758] lnd=0xa3552d38[0xa3552d38,0xa3552d38]
CHILD REFERENCES:
reference latch flags
--------- ----- -------------------
9da14758 5 CHL[02]
LIBRARY OBJECT: object=9da13ff0
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=2 size=16 --可见dependencies table结构仅会在ANONYMOUS LIST: 的library object handle中出现
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 9da13ab8 9da137f8 a355af28 16 DEP[01]
1 9da13ab8 9da138f8 a3552868 0 DEP[01]
ACCESSES: count=1 size=16
dependency# types
----------- -----
0 0009
TRANSLATIONS: count=1 size=16
original final
-------- --------
a355af28 a355af28
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a3552b88 9da14108 I/-/A/-/- 0 NONE 00 2.99 3.12
6 9da14528 9bb9f1d8 I/-/A/-/E 0 NONE 00 5.51 7.90
LIBRARY OBJECT HANDLE: handle=a3541fc0 mtx=0xa35420f0(0) lct=1 pct=2 cdp=0 --即对应child#=1的上述子游标的SQL
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=6 hpc=0000 hlc=0000
lwt=0xa3542068[0xa3542068,0xa3542068] ltm=0xa3542078[0xa3542078,0xa3542078]
pwt=0xa3542030[0xa3542030,0xa3542030] ptm=0xa3542040[0xa3542040,0xa3542040]
ref=0xa3542098[0x9d9cf240,0x9d9cf240] lnd=0xa35420b0[0xa35420b0,0xa35420b0]
CHILD REFERENCES:
reference latch flags
--------- ----- -------------------
9d9cf240 5 CHL[02]
LIBRARY OBJECT: object=9d9ceba8
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=2 size=16
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 9d9c58c0 9d9c5600 a3542c08 16 DEP[01]
1 9d9c58c0 9d9c5700 a3552868 0 DEP[01]
ACCESSES: count=1 size=16
dependency# types
----------- -----
0 0009
TRANSLATIONS: count=1 size=16
original final
-------- --------
a3542c08 a3542c08
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a3541f00 9d9cecc0 I/-/A/-/- 0 NONE 00 2.93 3.12
6 9d9cf0e0 9bb2c580 I/-/A/-/E 0 NONE 00 5.05 7.90
通过反向思维，可见如下的bucket对应ANONYMOUS LIST:的LIBRARY OBJECT HANDLE中的dependencies table
这里存储的是SQL的基表，即dependencies table结构存储SQL的基表
BUCKET 6797:
LIBRARY OBJECT HANDLE: handle=a355af28 mtx=0xa355b058(0) lct=5 pct=5 cdp=0
name=SCOTT.T_LIBRARYCACHE_TEST
hash=05c45c99776e0d8b6ac751c65d6a1a8d timestamp=11-23-2015 12:13:49
namespace=TABL flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-0701-0201 lock=N pin=0 latch#=1 hpc=0004 hlc=0004
lwt=0xa355afd0[0xa355afd0,0xa355afd0] ltm=0xa355afe0[0xa355afe0,0xa355afe0]
pwt=0xa355af98[0xa355af98,0xa355af98] ptm=0xa355afa8[0xa355afa8,0xa355afa8]
ref=0xa355b000[0xa355b000,0xa355b000] lnd=0xa355b018[0xa056f858,0xa3561368]
DEPENDENCY REFERENCES:
reference latch flags
--------- ----- -------------------
9da05028 7 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
9da137f8 5 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
9da03618 1 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
9d9c3340 1 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
LOCK OWNERS:
lock user session count mode flags
-------- -------- -------- ----- ---- ------------------------
9eb68b78 a4726cc0 a4726cc0 0 N [4044]
LIBRARY OBJECT: object=9da24a60
type=TABL flags=EXS/LOC[0005] pflags=[0000] status=VALD load=0
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a355ae68 9da24bb8 I/-/A/-/- 0 NONE 00 0.43 1.09
8 9da1baf0 9bb7be98 I/-/A/-/- 0 NONE 00 0.84 1.09
BUCKET 6797 total object count=1
可见authorization table结构仅存在于ANONYMOUS LIST中的library object handle
ANONYMOUS LIST:
LIBRARY OBJECT HANDLE: handle=a354e960 mtx=0xa354ea90(0) lct=4 pct=22 cdp=0
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=11 hpc=fffa hlc=fffa
lwt=0xa354ea08[0xa354ea08,0xa354ea08] ltm=0xa354ea18[0xa354ea18,0xa354ea18]
pwt=0xa354e9d0[0xa354e9d0,0xa354e9d0] ptm=0xa354e9e0[0xa354e9e0,0xa354e9e0]
ref=0xa354ea38[0x9da0a3a8,0x9da0a3a8] lnd=0xa354ea50[0xa354ea50,0xa354ea50]
CHILD REFERENCES:
reference latch flags
--------- ----- -------------------
9da0a3a8 0 CHL[02]
LIBRARY OBJECT: object=9da09c40
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=1 size=16
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 9da09708 9da09448 a39b2420 18 DEP[01]
AUTHORIZATIONS: count=1 size=16 minimum entrysize=18
0000 00000000 00004000 00000000 00000000
ACCESSES: count=1 size=16
dependency# types
----------- -----
0 0006
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a354e8a0 9da09d58 I/-/A/-/- 0 NONE 00 3.63 4.16
6 9da0a178 9bb516e0 I/-/A/-/E 0 NONE 00 20.03 23.74