共享池shared pool的概念
用户提交的命令:解析、执行
用户命令的解析
解析的过程是一个相当复杂的过程，它要考虑各种可能的异常情况比如SQL语句涉及到的对象不存在、提交的用户没有权限等等而且还需要考虑如何执行SQL语句采用什么方式去获职数据等解析的最终结果是要产生oracle自己内部的执行计划从而指导SQL的执行过程。可以看到，解析的过程是一个非常消耗资源的过程。因此oracle在解析用户提交的SQL语句的过程中如果对每次出现的新的SQL语句，都按照标准过程完整的从头到尾解析一遍的话效率太低尤其随着并发用户数量的增加、数据量的增加数据库的整体性能将直线下降。
shared pool=Library cache+dictionay cache
Library cache是重点；所有信息都放在dictionary cache
数据获取方式:全表/索引;表是如何连接；
代码共享----执行计划共享
SQL语句静态部分和动态部分：
oracle对SQL语句进行了概括和抽象将SQL语句提炼为两部分一部分是SQL语句的静态部分也就是SQL语句本身的关键词、所涉及的表名称以及表的列等另一部分就是SQL语句的动态部分.也就是SQL语句中的值(即表里的数据)很明显的，整个数据库中所包含的对象数量是有限的，而其中所包含的数据则是无限的，而正是这无限的数据导致了SQL语句的千变万化，也就是说在数据库运行的过程中发生的所有SQL语句中静态部分可以认为是有限的.而动态部分则是无限的。而实际上.动态部分对解析的影响相比静态部分对解析的影响来说是微乎其微.也就是说通常情况下对于相同的静态部分的SQL语句来说不同的动态部分所产生的解析结果(执行计划)基本都是一样的这也就为oracle提高解析SQL语句的效率提供了方向
Select····From····静态Where····动态
——————通过参数解决动态没有绑定变量的问题
共享池
oracle会将用户提交来的SQL语句都缓存在内存中。每次处理新的一条SQL语句时都会先在内存中查看是否有相同的SQL语句如果相同则可以减少最重要的解析工作〔也就是生成执行计划)从而节省了大量的资源：反之如果没有找到相同的SQL语句，则必须重新从头到尾进行完整的解析过程这部分存放SQL语句的内存就叫做共享池( shared pool)当然shared pool里不仅仅是SQL语句，还包括管理shared pool的内存结构以及执行计划、控制信息等等内存结构，oracle通过内存结构管理
绑定变量
当orocle在shared pool中查找相同的SQL语句的过程中如果SQL语句使用了绑定变量( bind variable ) ,那么就是比较SQL语句的静态部分。前面我们已经知道.静态部分是有限的，很容易就能够缓存在内存里从而找到相同的SQL语句的概率很高如果没有使用绑定变量.则就是比较SQL语句的静态部分和动态部分，而动态部分的变化是无限的.因此这样的SQL语句很难被缓存在shared pool里毕竟内存是有限的.不可能把所有的动态部分都缓存在shared pool里，即使能够缓存，管理这样一个无限大的shared pool也是不可能完成的任务。不使用绑定变量导致的直接结果就是，找到相同的SQL语句的概率很低.导致必须完整的解析SQL语句，也就导致消耗更多的资源。从这里也可以看出，只有我们使用了绑定变量才真正遵循了oracle引入shared pool的哲学思想，才能更有效的利用shared pool
共享池=库缓存+数据字典缓存
shared pool的大小由初始化参故shared_pool_size决定。10g以后可以不用设定该参数而只需要指定sga_target从而oracle将自动决定shared pool的大小尺寸,在一个很高的层次上来看.shared pool可以分为库缓存(library cache )和数据字典缓存(dictionarycache )Library cache存放了最近执行的SQL语句、存储过程、函数、解析树以及执行计划等而dictionary cache则存放了在执行SQL语句过程中,所参照的数据宇典的信息包活SQL语句所涉及的表名、表的列、权限信息等dictionary cache也叫做row cache,因为这里面的信息都是以数据行的形式存放的.而不是以数据块的形式存放的。对于dictionarycache来说oracle倾向于将它们一直缓存在shared pool里不会将它们交出内存.因此我们不用对它们进行过多的关注而librarycache则是shared pool里最重要的部分也是
在shared pool中进进出出最活跃的部分,需要我们仔细研究。所以我们在说到sharedpool实际上就可以认为是在指library caches
shared pool的内存结构(逻辑结构)
从一个逻辑层面来看shared pool由library cache和dictionary cache组成shared pool中组件之间的关系可以用下图一来表示。从下面这个图中可以看到当SQL语句(select objectid,objectname from sharedpool_test)进人library cache时，oracle会到dictionary cache中去找与sharedpool_test表有关的数据宇典信息比如表名、表的列等以及用户权限等信息如果发现dictionary cache中没有这些信息.则会将system表空间里的数据字典信息调入buffer cache内存.读取内存数据块里的数据字典内容，然后将这些读取出来的数据字典内容按照行的形式放入dictionary cache里，从而构造出dc_tables之类的对象然后，再从dictionary cache中的行数据中取出有关的列信息放入library cache中。
图：
shared pool结构(物理结构)
从一个物理的层面来看shared pool是由许多内存块组成这些内存块通常称为chunks，Chunk是shared pool中内存分配的最小单位一个chunk中的所有内存都是连续的，这些chunk可以分为四类。这四类可以从x$ksmsp(该视图中的每个行都表示shared pool里的
一个chunk)的ksmchcls字段看到:
SQL> select distinct(ksmchcls) from x$ksmsp:
recr
freeabl
R-freea
perm
no acce
R-free
free
已选择7行.
1) free
这种类型的chunk不包含有效的对象.可以不受限制的被分配
2）recr
意味着recreatable,这种类型的chunks里包含的对象可以在需要的时候被临时移走，
并且在需要的时候重新创建。比如对干很多有关共享SQL语句的chunks就是recreatable的
3)freeabl:这种类型的chunks包含的对象都是曾经被肥session使用过的.并且随后会被完全或部分释放的。这种类型的chunks不能临时从内存移走因为它们是在处理过程中问产生的如果移走的话就无法被重建
4) perm
意味着permanent 这种类型的chunk.包含永久的对象，大型的permanent类型的chunks也可能含有可用空间，这部分可用空间可以在需要的时候释放回shared pool里.
*****
Freeabl与会话有关如果移出无法重建
一堆的trunk
有多少个trunk就有多少个行
Ora-4013分配trunc时没有找到trunc
rerc清空不是移走，然后快速重建，因为有一部分信息已经存在
当chunk属于free类型的时候它既不属于library caehe也不属于dictionary caches如果该chunk被用于存放SQL游标时则该chunk进入librarycache，同样如果该chunk被用于存放数据字典的信息时.则该chunk进入dictionary eache
在shared pool里可用的chunk(free类型)会被串起来成为可用链表(free lists )，也可以叫做buckets(一个可用琏表也就是一个bucket)
我们可以使用下面的命令将.shared pool的内容转储出来看看这些bucket
alter seeeion set events'immediate trace name heapdump level 2';
然后打开产生的转储文件.找到“FREE LIST部分可以发现类似如下图所示的内容
SQL>alter session set events 'immediate trace name heppdump level 2';
会话已更改
FREE LISTS
Bucket 0 size=16
Ruckrt l size=20
Bucket 2 size=24
Bucket 3 size=28
Bucket 4 size=32
Bucket 5 size=36
Bucket 6 size=40
Rocket 7 size=44
················
Bucket 10 size=56
Bucket 11 size=60
Bucket 12 size=64
Bucket 13 size=68
Chunk6c3fffbcsz= 68 free " "
Bucket 14 size=72
Rueket IS size=75
每个bucket上挂的chunk的尺寸是不一样的，有一个递增的趋势。我们可以看到，每个bucket都有一个size字段‘这个size就说明了该bucket上所能链接的可用chunk的大小尺寸
****
如果出现很多小的trunc
1检查有没有bug,造成shared pool问题
2为什么会出现小的trunc ,因为在反复的不停的分配trunc ,代码没有共享
当一个进程需要shared pool里的一个chunk时.假设当前需要21个单位的空间则该进程首先到符合所需空间大小的bucket(这里就是bucket 2)上去扫描以找到一个尺寸最合适的chunk扫描持续到bucket的最末端.直到找到完全符合尺寸的chunk为止.如早找列的chunk的尺寸比需要的尺寸要大则该chunk就会被拆分成两个chunk，一个chunk被用来存放数据，而另外一个则成为free类型的chunk并被挂到当前该bucket上也就是bucket 2上然而,如果该bucket上不含有任何需要尺寸的chunk那么就从下一个非空的bucket上(这里就是bucket 3)获得一个最小的chunk，如果在剩下的所有bucket上都找到可用的chunk ,则需要扫描已经使用的recreatable类型的chunk链表从该链表上释放一部分的chunk出来因为只有receatable类型的chunk才是可以被临时移出内存的.
当某个chunk正在被使用时(可能是用户正在使用，也可能是使用了dbms_shared_pool包将对象钉在shared pool里)，该chunk是不能被移出内存的比如某个SQL语句正在执行,那么该SQL语句所对应的游标对象是不能被移出内存的，该SQL语句所引用的表、索引等对象所占用的chunk也是不能被移出内存的。当sharedpool中无法找到足够大小的所需内存时报ORA-4031错误。当出现4031错的时候你查询v$sgastat里可用的shared pool空间时可能会发现name为"free memory"的可用内存还足够大.但是为何还是会报4031错呢?事实上，在oracle发出4031错之前.已经释放了不少recreatable类型的chunk了，因此会产生不少可用内存但是这些可用chunk中.没有一个chunk是能够以连续的物理内存提供所需要的内存空问的从而才会发出4031的错
SQL> select * from v$sgastat where name=‘free memory’;
POOL NAME BYTES
shared pool free memory 7119640
large pool free memory 3988096
java pool free memory 4190304
****
l.share pool中的trunc是钉住的
2.sql-) share pool中行成行标很多的trunc会挂在一起
对bucket的扫描,管理、分配chunk等这些操作都是在shared pool lateh的保护下进行的。如果shared pool含有数量巨大的非常小的free类型的chunk的话.则扫描bucket时shared pool latch会被锁定很长的时间，这也是8i以前的shared pool later争用的主要原因而如果增加shared pool尺寸的话.仅仅是延缓shared pool latch的争用，而到最后，就会因为小的free chunks的越来越多，争用也越来越严重，而到了9i以后由于大大增加了可用chunk链表(也就是bucket)的数量.同时每个bucket所管理的可用chunk的尺寸递增的幅度非常小，于是就可以有效的将可用的chunk都均匀的分布在所有的bucket上，这样的结果就是每个bucket上所挂的free类型的chunk都不多.所以在查找可用chunk而持有shared pool latch的时间也可以缩短很多
**************
Free类型trunc
9i bucket增多，trunc就小了
1个lath管理多个bucket
1个cpu有一个latch
引起latch争用的原困是分配trunc时出的问题:1trunc太长，latch是串行的，读写都要先获取，即使是读，另一个进程获取latch只能等，一直等到时间片结束。lock是并行的，可以是同时读。大量分配trunc是连锁问题，加大bucket使trunc减小，latch增多，手工增加latch数量解决latch不够的问题****
对于非常大的对象oracle会为它们单独从保留区域里分配空间.而不是从这个可用chunk链表中来分配空问。这部分空间的大小尺寸就是由初始化参数shared_pool_reserved_size决定的缺省为shared_pool_size的5%，这块保留区域与正常的chunk的管理是完全分开的，小的chunk不会进入这块保留区域.而这块保留区域的可用chunk也不会挂在bucket上，这块保留区域的使用情况可以从视图v$shared_pool_reserved中看到。通常来说该视图的requestmisses字段显示了需要从保留区域的可用链表上上获得大的chunk而不能获得的次数该字段应该尽量为0。
SQL> show parameter shared_pool_reserved;
NAME TYPE VALUE
shared_pool_reserved_size biginteger 3774873
SQL, select repuests,repuest_misses from V$shared_pool_reserved；
REQUESTS REQUEST_MISSES
37 3
library cache最主要的功能就是存放用户提交的SQL语句、SQL语句相关的解析树〔解析树也就是对SQL语句中所涉及到的所有对象的展现)、执行计划、用户提交的PLSQL程序块〔包括匿名程序块、存储过程、包、函数等)以及它们转换后能够被orade执行的代码等，为了对这些内存结构进行管理还存放了很多控制结构包括lock, pin, dependency table等
library cache还存放了很多的数据库对象的信息，包括表、索引等等有关这些数据库对象的信息都是从dictionary cache中获得的。如果用户对library cache中的对象信息进行了修改，则这些修改会返回到dictionary cache中。
********
Sql文本解析树.执行计划
Sql涉及的对象信息〔不能每次都访问字典)
在library cache中存放的所有的信息单元都叫做对象〔object这些对象可以分成两类，一类叫存储对象，也就是上面所说的数据库对象，它们是通过显式的SQL语句或PL/SQL程序创建出来的，如果要删除它们.也必须通过显示的SQL命令进行删除此类对象包活表、视图、索引、包、函数等等；另一类叫做过渡对象池就是上面所说的用户提交的SQL语句或者提交的PL/SQL程序块等;这些过渡块在执行SQL语句或PL/SQL程序的过程中产生的，并缓存在内存里。如果实例关闭则删除.或者由于内存不足而被交换出去从而被删除
Sql和执行计划是过度对象，表的信息是存储对象
父子游标
当用户提交SQL语句或PLSQL程序块到oracle的shared pool以后，在library cache中生成的一个可执行的对象，这个对象就叫做游标(cusor)，不要把这里的游标与标准SQL(ANSI SQL)的游标混淆起来了，标准SQL的游标是指返回多条记录的SQL形式.需要定义、打开、关闭。下面所说到的游标如无特别说明都是指library cache中的可执行的对象。游标是可以被所有进程共享的也就是说如果100个进程都执行相同的SQL语句.那么这100个进程都可以同时使用该SQL语句所产生的游标从而节省了内存。每个游标都是由library cache中的两个或多个对象所体现的至少两个对象，一个对象叫做父游标(parentcursor)，包含游标的名称以及其他独立于提交用户的信息。从v$sqlarea视图里看到的都是有关父游标的信息;另外一个或多个对象叫做子游标〔child cursors ) ,如果SQL文本相同但是可能提交SQL语句的用户不同，或者用户提交的SQL语句所涉及到的对象为同名词等，都有可能生成不同的子游标，因为这些SQL语句的文本虽然完全一样.但是上下文环境却不一样因此这样的SQL语句不是一个可执行的对象必须细化为多个子游标后才能够执行，子游标含有执行计划或者PL/SQL对象的程序代码块等；
*******
执行对象:sql+执行计划十相关信息
游标是共享的
父游标:sql文本
子游标:具体的信息.子游标比父游标大
HASH算法
在介绍library cache的内部管理机制前先简单介绍一下所谓的hash算法
oracle内部在实现管理的过程中大量用到了hash算法。hash算法是为了能够进行快速查找定位所使用一种枝术所谓hash算法，就是根据要查找的值.对该值进行一定的hash算法后得出该值所在的索引号.然后进进入到该值应该存在的一列数值列表(可以理解为一个二维数组)里通过该索引号去找它应该属于哪一个列表然后再进人所确定的列表里对其中所含有的值进行一个一个的比较从而找到该值这样就避免了对整个数值列表进行扫描才能找到该值。这种全扫描的方式显然要比hash查找方式低效很多，其中每个索引号对应的数值列在oracle里都叫做一个hash bucket。
我们来列举一个最简单的hash算法.假设我们的数值列表最多可以有10个元素也就是有10个hash buckets ,每个元素最多可以包含20个数值。对应的二维数组就是t[10][20]我们可以定义hash算法为n MOD10通过这种算法可以将所有进入的数据均匀放在10个hash bucket里面hash bucket,编号从0到9,比如我们把1到100都通过这个hash函数均匀放到这10个hash bucket里，当查找32在哪里时只要将32 MOD 10等于2这样就知道可以到2号hash bucket里去找也就是到t[2][20]里去找2号hash bucket里有10个数值逐个比较2号hash bucket里是否存在32就可以了
library cache就是便用多个hash bucket来管理的‘其hash算法当然比我们前面列举的要复杂多了。每个hash bucket后面都串连着多个句柄〔该句柄叫做library cache object
handle )，这些句柄描述了library cache里的对象的一些属性包括名称、标记、指向对象所
处的内存地址的指针等。可以用下图来描述librarycaphe的整体结构
指针:指向文件结构的指针
Heap堆
Name:sql文件信息
Name space .名称空间
Look owner谁持有这个锁
Dependency table依赖表
Heap指向另外一些对象链表
图：
当一条SQL语句进入library cache的时候，先将SQL文本转化为对应ASCII数值然后对该这些ASCII数值进行hash函数的运算，传入函数的是SQL语句的名称( name对于
SQL语句来说其name就是SQL语句的文本)以及命名空间(namespace ,对于SQL语句来说是"SQL AREA",表示共享游标。可以从视图v$libarycache里找到所有的namespace)运用hash函数后得到一个值该值就是hash bucket的号码，从而该SQL语句被分配到该号的hash bucket里去，实际上.hash bucket就是通过串联起来的对象句柄才体现出来的.它本身是一个逻辑上的概念.是一个逻辑组，而不像对象是一个具体的实体。oracle根
据sharedpool_size所指定的shared pool尺寸自动计算hash buckets的个数.sharedpool越大则可以挂载的对象句柄就越多
SQL>select distinct(namespace) from v$librarycache;
NAMESPACE
BODY
JAVA DATA
SQL AREA
OBJECT
PIPE
JAVA RESOURCE
TABLE/PROCEDURE
TRIGGER
INDEX
JAVA SOURCE
CLUSTER
己选择11行
当某个进程需要处理某个对象时比如处理一条新进人的SQL语句时它会对该SQL语句应用hash函数算法以决定其所在的hash bucket的编号然后进入该hash bucket进行扫描并比较有可能会发生该对象的句柄存在但是句柄所指向的对象已经被交换出内存的情况出现，这时对应的对象必须被再次装载(reload)也可能该对象的句柄都不存在这时进程必须重新构建一个对象句柄挂到hash bucket上然后再重新装载对象SQL语句相关的对象有很多(最直观的就是SQL语句的文本)，这些对象都存放在library cache里它们都通过句柄来访问可以把library cache理解为一本书.而SQL语句的对象就是书中的页.而句柄就是目录.通过目录可以快速定位911指定内容的页对象，句柄存放了对象的名称(name ),对象所属的命名空间（namespace），有关对象的一些标记(比如对象是否为只读、为本地对象还是远程对象、是否被pin在内存中等等)以及有关对象的一些统计信息等，而且，对象句柄中还存放了当前正在lock住和pin住该对象的用户列表、以及当前正在等待lock和pin该对象的用户列表，对象句柄中存放的最重要的内容就是指向Heap 0对象的指针了。Heap 0用来存放与对象有直接关系的一些信息.比如对象类型、对象相关的表(比如依赖表、子表等)、指向对象的其他数据块的指针(这些数据块指向了实际存放SQL文本、PVSQL代码、错误信息等的大内存块，这些大内存块依次叫做Heap
1, 2, 3, 4等)等信息。
图