SharedPool原理

Shared pool和PGA都是由一個Oracle的內存管理器來管理，我們稱之為KGH heap manager。Heap Manager不是一個進程，而是一串代碼。

由于shared pool中最重要的是library cache，所以本文主要講解Library cache的結構，library cache latch，library cache lock，library cache pin。

What is shared pool?

Shared pool是SGA中的一部分，由于它是SGA的一部分，這意味著它可以被所有的進程所訪問，Shared Pool當中主要包含了2部分：library cache和

dictionary cache 也稱為 row cache。

Library cache包含了共享SQL區(shared SQL areas),私有SQL區(private SQLareas,如果配置了共享服務器),PL/SQL存儲過程以及包，還有一些控制信息，比如說locks以及library cache handles。

Dictionary cache包含了表，視圖的依賴信息，比如表結構，它的用戶，Oracle在解析SQL的時候就會頻繁的訪問dictionary cache。

How is it managed?

Shared pool和PGA都是由一個Oracle的內存管理器來管理，我們稱之為KGH heap manager。Heap Manager不是一個進程，而是一串代碼。Heap Manager主要目的就是滿足server 進程請求memory 的時候分配內存或者釋放內存。Heap Manager在管理PGA的時候，Heap Manager需要和操作系統來打交道來分配或者回收內存。但是呢，在shared pool中，內存是預先分配的，Heap Manager管理所有的空閑內存。當某個進程需要分配shared pool的內存的時候，Heap Manager就滿足該請求，Heap Manager也和其他ORACLE模塊一起工作來回收shared pool的空閑內存。

Library Cache Manager

Library cache Manager 可以看做是Heap Manager的客戶端，因為library cache manager是根據Heap Manager來分配內存從而存放library cache objects。Library cache Manager控制所有的library cache object，包括package/procedure, cursor, trigger等等。

Hash Table and Hash Bucket

Library cache是由一個hash table組成，這個hash table又由hash bucket組成的數組構成，每個hash bucket又是由一些相互指向的library cache handle所組成，library cache object handle就指向具體的library cache object以及一些引用列表。

Library Cache結構示意圖如下：

Library Cache handle

我們對Library cache中所有對象的訪問是通過利用library cache handle來實現的，也就是說我們想要訪問library cache object，我們必須先找到library cache handle。Library cache handle指向library cache object,它包含了library object的名字，命名空間，時間戳，引用列表，lock對象以及pin對象的列表信息等等。Library cache handle也被library cache用來記錄哪個用戶在這個這個handle上有lock，或者是哪個用戶正在等待獲得這個lock。那么這里我們也知道了library cache lock是發生在handle上的。

當一個進程請求library cache object, library cache manager就會應用一個hash 算法，從而得到一個hash 值，根據相應的hash值到相應的hash bucket中去尋找。這里的hash算法原理與buffer cache中快速定位block的原理是一樣的。如果library cache object在內存中，那么這個library cache handle就會被找到。有時候，當shared pool不夠大，library cache handle會保留在內存中，然而library cache heap由于內存不足被age out，這個時候我們請求的object heap就會被重載。最壞的情況下，library cache handle在內存中沒有找到，這個時候就必須分配一個新的library cache handle，同時object heap也會被加載到內存中。

Library Cache Object

Library Cache Object是由一些獨立的heap所組成，，前面說了Library cache handle指向Library cache Object，其實handle是指向第一個heap,這個heap 我們就稱之為heap 0。Heap 0記錄了指向其他heap的指針信息。

根據上面描述，Library cache中的的Library cache object結構示意圖可以用上圖來表示(本圖摘自DSI405)

Library cache lock/pin

Library cache lock/pin是用來控制對library cache object的并發訪問的。Lock管理并發，pin管理一致性，lock是針對于library cache handle,而pin是針對于heap。

當我們想要訪問某個library cache object，我們首先要獲得這個指向這個object的handle的lock，獲得這個lock之后我們就需要pin住指向這個object的heap。

當我們對包，存儲過程，函數，視圖進行編譯的時候，Oracle就會在這些對象的handle上面首先獲得一個library cache lock，然后再在這些對象的heap上獲得pin，這樣就能保證在編譯的時候其它進程不會來更改這些對象的定義，或者將對象刪除。

當一個session對SQL語句進行硬解析的時候，這個session就必須獲得library cache lock，這樣其他session就不能夠訪問或者更改這個SQL所引用的對象。如果這個等待事件花了很長時間，通常表明共享池太小(由于共享池太小，需要搜索free的chunk，或者將某些可以被移出的object page out，這樣要花很長時間)，當然了，也有可能另外的session正在對object進行修改(比如split 分區),而當前session需要引用那個table，那么這種情況下我們必須等另外的session進行完畢。

Library Cache lock有3中模式：

的時候獲得

修改一個library cache object的時候獲得

用來確保對象依賴性

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com