Oracle記憶體詳解之 Library cache 庫緩衝
Oracle記憶體詳解之 Library cache 庫緩衝
2017年11月09日 11:38:39 閱讀數：410更多
個人分類： 體系結構
Library cache是Shared pool的一部分，它幾乎是Oracle記憶體結構中最複雜的一部分，主要存放shared curosr（SQL）和PLSQL物件（function，procedure，trigger）的資訊，以及這些物件所依賴的table，index，view等物件的資訊。
Library cache需要解決三個問題：
1.快速定位的問題：Library cache中物件眾多，Oracle如何管理這些物件，以便服務程序可以迅速找到他們需要的資訊。比如某個服務程序需要迅速定位某個SQL是否存在於Library cache中。
2.關係依賴的問題：Library cache中的物件存在複雜的依賴關係，當某個objec失效時，可以迅速將依賴其的物件也置為失效狀態。比如某個表發生了結構變化，依賴其的SQL語句需要重新解析。
3.併發控制的問題：Library cache中必須有一個併發控制的機構，比如鎖機制，來管理大量共享物件的併發訪問和修改的問題，比如某個SQL在重新編譯的同時，其所依賴的物件不能被修改。
Library cache結構：
Oracle利用hash table結構來解決library cache中快速定位的問題，hash table就是很多hash bucket組成的陣列：
原理與buffer cache中定位block的方式相同，將物件資訊（比如SQL）hash定位到某個hash bucket中，然後順序掃描bucket中的 List，實現快速定位物件的目的。
Library cache handle是物件的一個指標，其中的namespace屬性表示其指向的物件的型別：比如CRSR(Cursor)，TABL(Table)，INDX(Index) ，PROD(Procedure)，TRIG(Trigger)等等。
LCO(Library cache object)是handel指向的物件，包含了以下幾個部分的內容：
1.dependency table：
指向本物件所依賴的物件，比如：select * from emp這個cursor的物件，依賴emp這個表，這裡指向了emp這個表的handle。
2.child table：
指向本物件的子物件，比如某個遊標的子游標。子游標是指SQL文字相同，但是SQL的實際含義不同的情況，比如執行的使用者不同，執行計劃不同，執行的環境不同等等，我們一般稱之為SQL的不同版本。一個SQL至少包含一個父遊標和一個子遊標。
3.authorization table：
物件的授權資訊。
4.type
Library cache object的type，包括：shared cursor,index,table,cluster,view,synonym,sequence,procedure,function,package,table body,package body,trigger等等。
5.data blocks
data block是一個指標，指向了data heap，即存放真實資料的地方，主要包括：diana tree, p-code, source code, shared cursor context area等等，如下圖：
Library cache物件依賴關係：
物件依賴關係是利用LCO中的dependency table來完成的，我們設想以下的情況，用來說明物件間的依賴關係：
兩個共享遊標：
SQL1: select * from emp;
SQL2: select * from emp和select a.name from emp a,dept b where a.dept_id=b.id and b.name=:1;
SQL1產生了兩個子游標，也就是SQL文字相同的兩個不同版本，他們同時依賴emp表。SQL2只有一個版本，因為每個遊標最少有一個子遊標，所以它只有一個子遊標，並且同時依賴dept表和emp表。
Library cache中的併發控制：
Oracle利用Library cache lock和Library cache pin來實現併發控制，Library cache lock是在handle上獲取的，而Library cache pin則是在data heap上獲取。訪問物件時，首先必須獲取handle上的lock，然後將訪問的資料pin在記憶體中。lock的作用是控制程序間的併發訪問，而pin的作用是保證資料一致性，防止資料在訪問時被交換出去。
Library cache lock有三種模式：null，share，exclusive，Library cache pin有兩種模式：share，exclusive。下面詳細解釋在修改和訪問物件時，lock和pin的作用：
修改物件：
編譯SQL或PLSQL物件，獲取該物件（cursor，procedure）handle上exclusive型別的lock，並且持有data heap上exclusive型別的pin，防止其他人讀取和修改。同時，在該物件所依賴的物件（table）上，必須持有一個share型別的lock和pin，防止在修改的過程中，被其他程序所修改。
訪問物件：
訪問SQL或PLSQL物件，獲取該物件（cursor，procedure）handle上NULL型別的lock，並且持有data heap上share型別的pin，同時，在其依賴的物件（table）上持有share型別的lock和pin。如果一個procedure依賴另外一個function，那麼在被依賴的function上，也需要持有share型別的lock和pin。
NULL型別的lock比較特殊，它只存在於cursor和procedure等只讀物件上，它並不起到任何併發控制的作用，它更象是一個trigger，當物件失效時，通知所有訪問這個cursor的程序。比如：select * from emp這個SQL，依賴emp表，當emp表發生變化時，cursor上的NULL lock被打破，所有有訪問這個cursor的程序都會知道該物件已經失效。
當持有物件的library cache pin時，會在row cache中對相應的物件加鎖，就是row cache lock，阻止可能導致資料字典資訊混亂的DDL發生。
lock和pin的實現類似於enqueue，在每個handle上都有lock和pin的holder list和waiter list，用來儲存持有該資源和等待該資源的佇列。
阻塞分析：
現實情況中，我們有一個數據庫中存在被應用大量頻繁訪問的procedure，當依賴的表發生變更時，導致該procedure失效，這時會出現大量的library cache lock和library cache pin的等待，堵塞應用訪問，造成了重大故障。出現這個問題的原因是：當procedure失效後，所有訪問該物件的程序都嘗試去編譯，大量程序嘗試獲取exclusive型別的lock和pin，出現了大量的等待。後續的Oracle版本作出了改進，當出現這種情況時，只允許第一個程序嘗試去編譯該物件，編譯通過後，所有的程序就可以併發訪問，避免了大量程序同時嘗試編譯的情況出現。
Library cache中的Latch：
Library cache中相關的latch包括：shared pool latch，library cahce latch，library cache lock latch，library cache pin latch。
Share pool latch的主要作用是分配或釋放空間時使用，從Oracle9i開始，sharedpool被分成了很多個subpool，由多個shared pool latch保護，Oracle開始支援更大的shared pool。
Library cache latch的主要作用是在hash bucket中定位handle時使用，library cache lock latch和library cache pin latch分別是獲取lock和pin時，需要取得的latch。
shared pool大小不合理，大量的硬解析以及SQL版本過多都可能導致shared pool latch和library cache latch的爭用。
從Oracle10g開始，Oracle正在逐步用mutex取代library cache中的latch，cursor：pin S和cursor：pin X相當於share和exclusive型別的library cache pin，cursor：pin S wait on X則表示share方式正在等待exclusive鎖定。
–EOF–
以下轉載
一. Library Cache 說明
LibraryCache 是Oracle SGA 中Shared pool 的組成部分。
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物件的列表資訊等等。
所以對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 [email protected]
Forexample, [email protected]
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 檔案來證明。在後面我們會做一個測試。
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中。 下面進行相關的測試，證明以上結論。
[email protected](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資訊
[email protected](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：
[email protected](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 出來，看一下：
[email protected](rac1)> alter session setevents 'immediate trace name heapdump_addr level 2,addr 0x2aa6d254';
Session altered.
--注意，這裡的addr前面加了0x。
[email protected](rac1)> oradebug setmypid
Statement processed.
[email protected](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 [[email protected]]
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.