Library cache位于Oracle實(shí)例SGA中的shared pool究履，用于緩存SQL游標(biāo)循未、PLSQL程序以及Java類的可執(zhí)行形式涂圆。

當(dāng)一條SQL運(yùn)行時(shí)泼返，如果它在不久前已經(jīng)被執(zhí)行過硝逢，那么Oracle會(huì)嘗試重用這條SQL的。一條從未執(zhí)行過的SQL進(jìn)入數(shù)據(jù)庫(kù)獲取數(shù)據(jù)需要經(jīng)過編譯和解析绅喉，然后生成最終的可以直接調(diào)用的執(zhí)行計(jì)劃結(jié)果渠鸽，再按照這個(gè)執(zhí)行計(jì)劃來(lái)從相關(guān)的數(shù)據(jù)庫(kù)表中獲取數(shù)據(jù)。如果語(yǔ)句解析后的結(jié)果已經(jīng)緩存在了library cache中柴罐，那它就能夠被重用徽缚，這就叫做軟解析，或者叫library cache hit革屠。相反凿试，如果library cache中沒有緩存排宰，則必須重新解析生成新的執(zhí)行計(jì)劃，然后放入library cache中執(zhí)行那婉，這就叫做硬解析板甘，或者叫library cache miss。

當(dāng)執(zhí)行SQL時(shí)详炬，library cache miss可以發(fā)生在解析階段或執(zhí)行階段盐类。當(dāng)解析調(diào)用SQL語(yǔ)句時(shí)，如果語(yǔ)句的解析表達(dá)式不存在于library cache中呛谜，數(shù)據(jù)庫(kù)會(huì)解析語(yǔ)句然后將解析后的結(jié)果存放在shared pool中在跳。

• 硬解析：
  提交一條SQL語(yǔ)句，并且shared pool中是找不到匹配的項(xiàng)隐岛。硬解析是資源集中型操作猫妙，因此擴(kuò)展性不強(qiáng)，因?yàn)橐粋€(gè)語(yǔ)句解析操作會(huì)包含大量復(fù)雜的工作聚凹。
• 軟解析：
  提交一條SQL語(yǔ)句割坠，并且shared pool中能夠找到匹配的項(xiàng)。這個(gè)匹配的項(xiàng)可以是另一個(gè)用戶之前執(zhí)行后生成的元践。SQL語(yǔ)句被共享，這能夠提升性能童谒。但是单旁，軟解析也并不完美，因?yàn)樗麄內(nèi)匀恍枰Z(yǔ)法和安全性檢查（受DDL語(yǔ)句影響）饥伊，仍然要耗費(fèi)系統(tǒng)資源象浑。

硬解析應(yīng)該盡可能少，所以應(yīng)用開發(fā)人員在設(shè)計(jì)系統(tǒng)時(shí)應(yīng)該考慮如何讓SQL語(yǔ)句在只解析一次的情況下執(zhí)行更多次琅豆。這需要用到游標(biāo)（cursors）愉豺。有經(jīng)驗(yàn)的SQL程序員應(yīng)該熟練掌握打開和重執(zhí)行游標(biāo)的概念。

必須確保SQL語(yǔ)句在共享池中被共享茫因。使用綁定變量來(lái)表式多個(gè)相似SQL語(yǔ)句中不一樣的部分蚪拦。否則，有可能出現(xiàn)特別多的語(yǔ)句在第一次解析之后就再也不會(huì)被重用冻押。

例如：

SELECT * FROM employees 
  WHERE last_name LIKE 'KING';

應(yīng)該改成

SELECT * FROM employees 
  WHERE last_name LIKE :1;

library cache結(jié)構(gòu)和概念

所有SQL和PLSQL語(yǔ)句的執(zhí)行計(jì)劃都存放在Library cache內(nèi)存區(qū)

而library cache可以進(jìn)一步劃分為：

• 共享SQL區(qū)和私有SQL區(qū)
• PLSQL存儲(chǔ)過程部分

共享的和私有的SQL區(qū)域

共享的SQL區(qū)包含一條單獨(dú)SQL語(yǔ)句或多條相似SQL的解析樹和執(zhí)行計(jì)劃驰贷。Oracle讓多條相似的DML語(yǔ)句使用同一個(gè)共享SQL區(qū)，從而達(dá)到節(jié)省內(nèi)存的目的洛巢。尤其是當(dāng)多個(gè)用戶使用同一個(gè)應(yīng)用時(shí)括袒。

共享SQL區(qū)總是在shared pool中。解析一條SQL語(yǔ)句時(shí)會(huì)從shared pool中請(qǐng)求內(nèi)存稿茉。如果一條SQL語(yǔ)句需要新的SQL區(qū)锹锰，但shared pool中沒有剩余空間時(shí)芥炭，Oracle會(huì)根據(jù)LRU算法來(lái)清理pool中的內(nèi)容，直到空間足夠分配新的共享SQL區(qū)恃慧。

私有SQL區(qū)包含類似于綁定信息和運(yùn)行時(shí)緩存這類數(shù)據(jù)园蝠。每個(gè)執(zhí)行SQL的會(huì)話都有一個(gè)私有SQL區(qū)。每個(gè)提交SQL語(yǔ)句的會(huì)話用戶都有自己的私有SQL區(qū)糕伐，這個(gè)私有SQL區(qū)只會(huì)使用一個(gè)單獨(dú)的共享SQL區(qū)砰琢。而同一個(gè)共享SQL區(qū)可以和多個(gè)私有SQL區(qū)關(guān)聯(lián)使用。

私有SQL區(qū)里有一個(gè)固有區(qū)和一個(gè)運(yùn)行時(shí)區(qū)：

• 固有區(qū)包含多次執(zhí)行且重復(fù)使用的綁定信息良瞧，數(shù)據(jù)類型轉(zhuǎn)換代碼（當(dāng)數(shù)據(jù)類型定義和所選列數(shù)據(jù)類型不一致時(shí)）陪汽，以及其他狀態(tài)信息（比如，循環(huán)或遠(yuǎn)程游標(biāo)數(shù)量或者并行查詢的狀態(tài)）褥蚯。固有區(qū)的大小取決于綁定變量和語(yǔ)句查詢列的個(gè)數(shù)挚冤，比如，如果一條查詢中出現(xiàn)了許多列赞庶，則固有區(qū)會(huì)更大
• 運(yùn)行時(shí)區(qū)包含SQL語(yǔ)句被執(zhí)行時(shí)需要使用的信息训挡。大小取決于SQL語(yǔ)句的類型和復(fù)雜程度以及語(yǔ)句處理的行的大小。通常歧强，INSERT澜薄、UPDATE、DELETE的運(yùn)行時(shí)區(qū)比SELECT語(yǔ)句的運(yùn)行時(shí)區(qū)更小摊册，尤其是對(duì)于需要排序的SELETE語(yǔ)句肤京。
  oracle在收到執(zhí)行請(qǐng)求的第一時(shí)間就開始創(chuàng)建運(yùn)行時(shí)區(qū)。對(duì)于INSERT茅特、UPDATE忘分、DELETE語(yǔ)句，oracle會(huì)在執(zhí)行完成后釋放掉運(yùn)行時(shí)區(qū)白修。對(duì)于SELECT查詢妒峦，Oracle會(huì)等到所有行被提取后或者查詢被取消后才會(huì)釋放運(yùn)行時(shí)區(qū)內(nèi)存。
  私有SQL區(qū)的位置取決于會(huì)話建立連接的類型兵睛。如果是專有服務(wù)器連接模式肯骇，私有SQL區(qū)位于用戶的PGA。如果是共享服務(wù)器連接模式祖很，則固有區(qū)累盗、和SELECT查詢的運(yùn)行時(shí)區(qū)
  都會(huì)存放在SGA。
  x$ksmss表中提供了關(guān)于library cache中SQL區(qū)的運(yùn)行時(shí)信息

PLSQL過程部分

oracle處理PLSQL程序和處理單獨(dú)SQL語(yǔ)句的方式大致相同突琳。

oracle分配共享區(qū)來(lái)存放程序單元的解析若债、編譯形式，分配私有區(qū)來(lái)存放每個(gè)會(huì)話在執(zhí)行程序單元時(shí)特有的值拆融，其中包括本地變量蠢琳、全局變量啊终、和package變量以及執(zhí)行SQL時(shí)需要的緩存。如果多個(gè)會(huì)話執(zhí)行同一個(gè)程序單元傲须，所有會(huì)話共享一個(gè)共享區(qū)蓝牲，而各個(gè)會(huì)話維護(hù)各自的私有SQL區(qū)，持有各自會(huì)話特有的值泰讽。
PLSQL程序單元中的單獨(dú)SQL語(yǔ)句和PLSQL程序外的SQL語(yǔ)句一樣例衍，盡管處于PLSQL程序單元中，這些SQL語(yǔ)句仍然使用共享區(qū)來(lái)持有解析形式已卸，使用私有區(qū)來(lái)存放會(huì)話特有的信息佛玄。
x$ksmss表中提供了關(guān)于library cache中PLSQL區(qū)的運(yùn)行時(shí)信息

Library Cache管理器

library cache的主要目的是提供一種快速定位和存儲(chǔ)library cache object（LCO）的機(jī)制。使用一種hash機(jī)制來(lái)定位含有object id的handle累澡。library cache handle（LCH）指向一個(gè)或多個(gè)library cache objects以及它們的內(nèi)容

library cache緩存了不同類型的library cache object（比如梦抢，packages，procedures愧哟，functions奥吩，shared cursors，命名PLSQL塊蕊梧，表定義霞赫，視圖定義，form定義）

KGH heap Manager：
shared pool和PGA都是由一個(gè)Oracle的內(nèi)存管理器來(lái)管理肥矢，我們稱之為KGH heap manager端衰。它不是一個(gè)進(jìn)程，而是一串代碼橄抹。heap Manager主要目的是滿足server進(jìn)程請(qǐng)求內(nèi)存的時(shí)候分配內(nèi)存或者釋放內(nèi)存靴迫。Heap Manager在管理PGA的時(shí)候惕味，需要和操作系統(tǒng)打交道來(lái)分配或者回收內(nèi)存楼誓。但是，在shared pool中名挥，內(nèi)存是預(yù)先分配的疟羹，Heap Manager管理所有的空閑內(nèi)存。
當(dāng)某個(gè)進(jìn)程需要分配share pool的內(nèi)存的時(shí)候禀倔，Heap Manager就滿足該請(qǐng)求榄融，heap manager也和其他Oracle模塊一起工作來(lái)回收shared pool的空閑內(nèi)存。

library cache內(nèi)存是從SGA heap的最頂端開始分配內(nèi)存救湖。當(dāng)Library cache需要更多內(nèi)存的時(shí)候愧杯，會(huì)調(diào)用KGH heap manager來(lái)分配。Library cache是由一個(gè)hash表組成鞋既，hash表是一個(gè)由許多hash buckets組成的向量力九。每個(gè)hash bucket是由多個(gè)LCH組成的雙鏈列表耍铜。每個(gè)handle指向一個(gè)object并且有一個(gè)reference list。

Library Cache Manager（hash表和hash bucket）

Library cache manager（LCM）可以看做是Heap Manager的客戶端跌前，因?yàn)長(zhǎng)CM是根據(jù)Heap Manager來(lái)分配內(nèi)存從而存放LCO棕兼。LCM控制著所有的LCO，包括package/procedure,cursor,trigger等等抵乓。

library cache是有hash table組成伴挚，這個(gè)hash table又由hash bucket組成的數(shù)組構(gòu)成，每個(gè)hash bucket又是由一些相互指向的LCH組成灾炭，LCH指向具體的LCO以及一些引用列表茎芋。

hash table初始化由251個(gè)hash buckets組成，當(dāng)hash table中的buckets不夠用時(shí)咆贬，會(huì)自動(dòng)擴(kuò)展長(zhǎng)度败徊，每次擴(kuò)展之后，buckets數(shù)量大約是原來(lái)的2倍掏缎，但這個(gè)值必定是一個(gè)質(zhì)數(shù)皱蹦。準(zhǔn)確地講，如果是第n次擴(kuò)展眷蜈，則擴(kuò)展后的長(zhǎng)度為不大于2^(n+8)的最大質(zhì)數(shù)沪哺。hash table在擴(kuò)展的時(shí)候，實(shí)際上是新建了一個(gè)長(zhǎng)度大約為原來(lái)2倍的新的hash table酌儒，然后將原來(lái)hash table上的對(duì)象重新組織在新的hash table上辜妓，因此，hash table在擴(kuò)展的時(shí)候是不可訪問的忌怎。但這是一個(gè)不怎么耗資源的操作籍滴，一般來(lái)說(shuō)3-5秒內(nèi)即可完成。

hash table只會(huì)擴(kuò)展不會(huì)收縮榴啸。

Library Cache Handle

Library Cache Handle（LCH）執(zhí)行Library cache object(LCO).它里面含有LCO的name孽惰、namespace、timestamp鸥印、reference list勋功、lock請(qǐng)求列表和pin請(qǐng)求列表。每個(gè)LCO都是通過LCH里的name和namespace聯(lián)合起來(lái)作為唯一標(biāo)識(shí)库说。

共享池：library cache統(tǒng)計(jì)

在規(guī)劃共享池大小時(shí)狂鞋，我們的目的是確保多次執(zhí)行的SQL語(yǔ)句被緩存在library cache中，不需要分配太多內(nèi)存潜的。

v$librarycache視圖是用于統(tǒng)計(jì)自最近一次數(shù)據(jù)庫(kù)重啟以來(lái)的library cache中各個(gè)組件的使用情況骚揍。

v$librarycache視圖中的reload列表示被踢出緩存的SQL語(yǔ)句被再次執(zhí)行硬解析的次數(shù)。這個(gè)值應(yīng)該盡可能少或接近于0.

v$librarycache視圖中的invalidations列表示library cache中的數(shù)據(jù)失效啰挪，從而需要重新解析的次數(shù)信不，通常纤掸，DDL語(yǔ)句改變了元數(shù)據(jù)使得SQL語(yǔ)句解析緩存失效時(shí)，這個(gè)值會(huì)增加浑塞。

另一個(gè)關(guān)鍵指標(biāo)是共享池在業(yè)務(wù)高峰期的剩余內(nèi)存借跪。可以通過v$sgastat視圖查看酌壕。剩余內(nèi)存應(yīng)該盡可能少

SQL解析執(zhí)行全過程總結(jié)：

當(dāng)一條SQL進(jìn)來(lái)：

• 如果這條SQL為全新文本
  文本經(jīng)過hash算法生成哈希值掏愁，到PGA里去匹配，除非出現(xiàn)hash碰撞（概率極新央埂）果港，否則不可能找到，所以需要到SGA里的shared pool里的library cache里找糊昙，因?yàn)槭侨挛谋拘谅樱詌ibrary cache中也肯定不會(huì)有現(xiàn)成的（除非hash碰撞），因此需要進(jìn)行硬解析释牺，也就是萝衩，在library cache中的hash buckets鏈中新增一個(gè)bucket，這個(gè)bucket里會(huì)存放一個(gè)parent cursor和一個(gè)child cursor没咙，parent cursor和child cursor具有相同的結(jié)構(gòu)猩谊，統(tǒng)稱為shared cursor，是library cache中存放的幾十種library cache object中的一種祭刚。parent cursor和child cursor雖然具有相同的結(jié)構(gòu)牌捷，但他們的功能不一樣parent cursor數(shù)據(jù)結(jié)構(gòu)里主要存放的是SQL文本，存放在name屬性里涡驮，不存放SQL的解析樹和執(zhí)行計(jì)劃暗甥，而child cursor的name屬性為空，主要用于存放SQL的解析樹和執(zhí)行計(jì)劃捉捅。parent cursor和child cursor從功能上講是從屬關(guān)系撤防，一個(gè)parent cursor可以掛一個(gè)或多個(gè)child cursor，新建的bucket下會(huì)初始化生成一個(gè)parent cursor和一個(gè)child cursor锯梁。新增bucket的過程中會(huì)持有l(wèi)ibrary cache latch即碗，維護(hù)新增操作的原子性焰情，同時(shí)需要為新增的bucket分配內(nèi)存陌凳，所以還要持有shared pool latch。當(dāng)新的bucket生成并成功返回給PGA后内舟，shared pool和library cache
  latch才能得以釋放合敦，然后才會(huì)在PGA里對(duì)cursor進(jìn)行open、parse验游、bind充岛、execute保檐、fetch、closed（或soft closed）等操作崔梗。

• 如果這條SQL曾經(jīng)執(zhí)行過夜只，至少SQL文本相同
  文本經(jīng)過hash算法生成哈希值，PGA中有可能有現(xiàn)成的蒜魄，也有可能沒有扔亥，取決于session_cached_cursors參數(shù)，這個(gè)參數(shù)控制著PGA里是否緩存執(zhí)行過的cursors谈为，緩存多少個(gè)旅挤。如果PGA里有現(xiàn)成的，說(shuō)明當(dāng)前會(huì)話在不久前執(zhí)行過這條SQL伞鲫，并且cursor在open并使用之后被標(biāo)記為了closed粘茄，并未真正意義上的被清理出PGA，這就叫soft closed秕脓，PGA可以直接對(duì)這個(gè)已經(jīng)緩存的session cursor進(jìn)行操作柒瓣，不需要open一個(gè)新的session cursor。 這樣的SQL解析叫做軟軟解析吠架，是消耗資源最少的一種解析方式嘹朗。如果一條SQL文本在數(shù)據(jù)庫(kù)里執(zhí)行過，但PGA里沒有現(xiàn)成的诵肛，原因有可能是：
  （1） 其他會(huì)話執(zhí)行過屹培，當(dāng)前會(huì)話沒執(zhí)行過
  （2） 當(dāng)前會(huì)話執(zhí)行過，但沒有緩存（session_cached_cursors參數(shù)控制）
  如果是原因（1）怔檩，該SQL文本在其他會(huì)話執(zhí)行過褪秀，PGA會(huì)根據(jù)SQL文本對(duì)應(yīng)的hash值到library cache中的hash buckets鏈中搜索，找到對(duì)應(yīng)的bucket以及parent cursor薛训，然后順著parent cursor一一驗(yàn)證掛在其下的child cursor媒吗，child cursor有可能有多個(gè)，因?yàn)殡m然SQL文本相同乙埃，SQL執(zhí)行環(huán)境未必相同闸英，比如SQL執(zhí)行的用戶不同則語(yǔ)句涉及的表或試圖等對(duì)象也可能不同，會(huì)話參數(shù)不同則產(chǎn)生的解析樹和執(zhí)行計(jì)劃也有可能不同介袜，因?yàn)槭瞧渌麜?huì)話執(zhí)行的甫何，所以執(zhí)行環(huán)境也不盡相同。如果經(jīng)過驗(yàn)證能夠在bucket中找到可以復(fù)用的child cursor遇伞，則將該child cursor返回給PGA辙喂，這中情況屬于軟解析。如果沒有可以復(fù)用的child cursor，則會(huì)在bucket中新增一個(gè)child cursor巍耗，然后返回給PGA作為session cursor進(jìn)行后續(xù)操作秋麸。新增child cursor仍然需要從shared pool中分配內(nèi)存，持有shared pool latch和library cache latch（或mutex）炬太，所以這也屬于硬解析灸蟆。區(qū)分硬解析于軟解析的關(guān)鍵點(diǎn)在于是否新增child cursor。
  如果是原因（2）亲族，在同一個(gè)會(huì)話中次乓，第二次執(zhí)行相同的SQL文本，由于PGA中的緩存沒有了孽水，于是到Library cache的hash buckets鏈中按照SQL文本的hash值搜索票腰，根據(jù)parent cursor找到SQL文本相同的bucket，然后搜索掛在這個(gè)bucket下的child cursor女气，如果能夠找到可以復(fù)用child cursor杏慰，然后就返回給PGA。雖然是第二次執(zhí)行炼鞠，仍然有可能找不到可以復(fù)用的child cursor缘滥。實(shí)際上，child cursor是掛在hash buckets鏈的一個(gè)支鏈上的二進(jìn)制可執(zhí)行文件谒主，屬于library cache object朝扼，每個(gè)library cache object都有一個(gè)handle，這個(gè)handle上有個(gè)叫heap 0的數(shù)據(jù)結(jié)構(gòu)霎肯，heap 0中存放了能夠驗(yàn)證child cursor是否能夠復(fù)用的驗(yàn)證信息擎颖，比如，SQL語(yǔ)句涉及哪些對(duì)象（準(zhǔn)確地說(shuō)观游，是哪些library cache object）搂捧，heap 0中還存放了執(zhí)行child cursor二進(jìn)制可執(zhí)行文件（data heap中）的地址指針，以便能夠順著handle找到child cursor懂缕。handle中僅包含驗(yàn)證信息和指針等較小的數(shù)據(jù)結(jié)構(gòu)允跑，因此占用空間很少，而child cursor才是存放解析樹和執(zhí)行計(jì)劃等空間占用較多的數(shù)據(jù)結(jié)構(gòu)搪柑。因此聋丝，當(dāng)shared pool空間不足時(shí)，會(huì)根據(jù)LRU算法將掛在handle下的child cursor二進(jìn)制可執(zhí)行文件清理出內(nèi)存工碾，但handle仍然保留弱睦，當(dāng)handle再次被成功驗(yàn)證可以復(fù)用，卻找不到二進(jìn)制可執(zhí)行文件時(shí)倚喂，需要重新生成執(zhí)行計(jì)劃和解析樹每篷，然后在支鏈上新增一個(gè)handle，并將child cursor掛在新增的handle上端圈，然后才將原來(lái)的空handle拿掉焦读，這種情況叫做reload，仍然屬于硬解析舱权。當(dāng)然如果是原因（1）矗晃，同樣有可能出現(xiàn)這種情況。

library cache pin和library cache lock

• 簡(jiǎn)介
  library cache lock和library cache pin都是用于管理不同進(jìn)程對(duì)library cache中的對(duì)象的并發(fā)訪問的宴倍。但是library cache pin用于管理cache 的一致性张症。要想訪問library cache 中的對(duì)象，必須先lock住library cache object handle鸵贬，然后pin住對(duì)象的data heap本身俗他。pin和lock請(qǐng)求在被許可之前都需要一直等待。這就有可能引起資源的競(jìng)爭(zhēng)阔逼，因?yàn)閮煞N請(qǐng)求都不存在NOWAIT請(qǐng)求模式兆衅。
  當(dāng)一個(gè)進(jìn)程獲取了某個(gè)object handle的library cache lock的時(shí)候，其他進(jìn)程便不能訪問這個(gè)對(duì)象嗜浮，甚至連這個(gè)object是什么類型的都無(wú)法得知羡亩。lock還可以維護(hù)一個(gè)object的依賴關(guān)系，但不會(huì)阻止其他進(jìn)程訪問依賴的對(duì)象危融。

如果進(jìn)程想要真正使用或修改這個(gè)object畏铆，那么必須獲得object data heap 本身的library cache pin，也就是在獲得lock之后獲得吉殃。pin住object的過程中辞居，如果data heap的信息和數(shù)據(jù)被aged out，則必須將它們重新加載進(jìn)來(lái)蛋勺。data heap被pin住的時(shí)候速侈，不能被aged out出內(nèi)存。lock和pin的信息可以分別通過x$kgllk和x$kglpn兩個(gè)視圖查看

library cache lock模式

• library cache lock有三種模式迫卢，分別為share倚搬、exclusive、null乾蛤。

如果只是讀取object每界，則獲取（S）share模式的鎖家卖；如果需要修改object眨层，則獲壬系础（X）exclusive模式的鎖馒闷；Null鎖比較特殊叁征，用于維護(hù)object的依賴對(duì)象，在訪問object的時(shí)候會(huì)一直持有捺疼，持有期間疏虫，object的依賴對(duì)象可以被其他進(jìn)程訪問甚至修改卧秘，通常，如果依賴對(duì)象被修改官扣，則Null鎖被打破，object會(huì)被標(biāo)記為invalid惕蹄。object下次被訪問時(shí)哼御，則需要重新解析成二進(jìn)制可執(zhí)行文件。

• library cache pin模式
  library cache pin有兩種模式焊唬，分別是share和exclusive恋昼。一般來(lái)說(shuō)，share模式lock用于只讀訪問赶促，exclusive模式lock用于修改液肌。但無(wú)論只讀訪問還是修改，總是要先獲取object 的share lock鸥滨，進(jìn)行錯(cuò)誤檢查和安全性檢查嗦哆，然后，如果需要修改object婿滓，再追加exclusive lock老速。如果一個(gè)object只需要只讀訪問，就絕不會(huì)被exclusive pin凸主。這是因?yàn)楫?dāng)object