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 isSCHEMA.NAME@DBLINK.
Forexample, HR.EMPLOYEES@ACME.COM
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中。 下面进行相关的测试，证明以上结论。
SYS@anqing1(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信息
SYS@anqing1(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：
SYS@anqing1(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 出来，看一下：
SYS@anqing1(rac1)> alter session setevents 'immediate trace name heapdump_addr level 2,addr 0x2aa6d254';
Session altered.
--注意，这里的addr前面加了0x。
SYS@anqing1(rac1)> oradebug setmypid
Statement processed.
SYS@anqing1(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 [....V.......@...]
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.
