深入理解shared pool共享池之library cache系列一
背景
為了更為直觀理解library cache,貼2張相關圖，如下：
結論
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
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/9240380/viewspace-1844964/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 深入理解shared pool共享池之library cache系列二
- 深入理解shared pool共享池之library cache的library cache lock系列四
- 深入理解shared pool共享池之library cache的library cache pin系列三
- 深入理解shared pool共享池空間及library cache分配之ora-4031 系列一
- 共享池之六:shared pool latch/ library cache latch /lock pin 簡介
- 基於引數shared_pool_reserved_size進一步理解共享池shared pool原理
- zt_Oracle shared pool internals_共享池_shared_poolOracle
- 等待模擬-library cache shared pool 硬解析
- Shared pool的library cache lock/pin及硬解析
- 優化Shared Pool Latch與Library Cache Latch競爭優化
- shared pool library cache latch 競爭優化辦法優化
- shared pool之三：library cache結構/library cache object的結構-dump LibraryHandleObject
- 共享池之五：Shared Pool子池與結果集快取技術快取
- zt_eygle大師_shared pool共享池管理機制系列文章
- Flush an Object Out The Library Cache [SGA] Using The DBMS_SHARED_POOLObject
- Shared Pool優化和Library Cache Latch衝突優化優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列6優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列5優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列4優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列3優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列2優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列1優化
- 深入淺出buffer cache和shared pool記載01
- 深入淺出cache buffer和shared pool記載02
- 深入淺出buffer cache和shared pool記載03
- 資料庫體系結構-共享池(shared pool)，largepool,Java池，流池資料庫Java
- oracle調優之-共享池尺寸調優+library cache+dicitonary library 命中率Oracle
- 使用DBMS_SHARED_POOL包將物件固定到共享池物件
- 共享池的調整與優化(Shared pool Tuning)優化
- 故障排除：Shared Pool優化和Library Cache Latch衝突優化優化
- 理解Oracle Shared PoolOracle
- latch:shared pool的一點理解
- 深入理解Java併發框架AQS系列（四）：共享鎖（Shared Lock）Java框架AQS
- library cache lock和library cache pin理解
- 《深入解析Oracle》第六章，Buffer Cache與Shared Pool原理Oracle
- library cache內容系列一之library hash bucket--library object handle--heapObject
- Shared pool深入分析及效能調整(一)
- oracle10g_oracle11g_library cache_shared pool管理方面的小區別Oracle