shared pool分析
解析SQL语句、生成执行计划、
 
解析SQL  ------------|
|    |---需要考虑访问对象是否存在，权限时候具有等因素
生成执行计划--------|
|      
执行SQL语
 
解析的过程是一个耗费资源的过程，随着用户的并发数量的增加。数据库的性能也会降低的很快。
在mysql中没有绑定变量的概念，在oracle中我们可以使用绑定变量来大幅减少我们的SQL解析次数。
 
ORCLE对解析的执行
1、ORACLE将SQL语句分成为两个部分
静态部分+动态部分
2、静态部分
SQL 语句的关键词
所涉及的表名称、列名称、等
3、动态部分
字面值（表里面的表数据）
例如 where name=‘ace’
那么where name是静态部分、ace是动态部分
静态部分是有限的、动态部分是无限的
在实际中，不同的SQL语句的静态部分的重复率非常的高、动态部分导致了SQL语句的千变万化
实际上，静态部分对SQL语句的解析的影响可以忽略不计，主要是动态部分
 
ORCLE将解析过的SQL语句缓存在shared pool中，碰到相同的SQL语句再次执行的时候，ORACLE直接使用已经解析过的执行计划。
Shared pool中缓存的内容包括
1、SQL语句
2、执行计划
3、PL/SQL代码
4、PL/SQL机器码等
 
通过使用绑定变量，用来提高SQL语句的缓存命中率
declare
v1 varchar2(10);
i1  int(10);
begin
i1:=1;
select name into v1 from dba_team where id=i1;
end;
/
在上面的SQL语句中，使用了绑定变量i1，在解析的时候，使用的绑定变量。执行的时候，将字面值传入语句中。因此这样SQL语句的命中率将会提高。
使用绑定变量是一个很好的思路。
在SQL语句中，更多的使用绑定变量、特别是大型的复杂SQL查询
 
Shared pool细分
1、库缓存
最近执行的SQL语句、存储过程、函数、解析树、执行计划
最活跃部分
2、数据字典缓存
SQL执行过程中涉及的数据字典
Shared Pool的内存结构（物理结构）
Shared pool由许多的内存块组成，这些内存块称为chunk
1、chunk是shared pool中内存分配的最小单元（类似于extent）
2、一个chunk在内存中是连续的
Chunk的分类
1、free：chunk中没有有效的对象，可以不受限制的分配
如果用于存放和SQL相关的数据，那么chunk就属于 library cache，如果用于存放数据字典，那么这个chunk就属于 dictionary cache
2、recr：recreatable，chunk里面包含的对象可以被临时性的移 走，如果需要，可以重建，例如共享SQL语句.上面例子中的i1解析完后就存放在这里。
3、freeabl：session用过这个trunk，里面存放的对象数据是session在处理过程中产生的，没有办法重建，这点不同于recr。因此这个chunk不能被临时性的移走。但是在合适的时间段（一般在seesion结束）可以被释放。
4、perm：permanent，chunk中包含永久性的对象，但是大型的permanent类型的chunk中可能包含可用空间，需要的时候，这些空间可以被释放。例如v$表的中参数。
 
查看当前数据库中正在使用的chunk，稍后我会抓取trace文件给大家展示下。
SQL> select count(*),KSMCHCLS  from x$ksmsp group by KSMCHCLS;
 
  COUNT(*) KSMCHCLS
---------- --------
     14938 freeabl
     30131 recr
54 R-freea
23 perm
27 R-free
      2777 free
 
查看当前内存地址在使用哪个chunk
SQL> select ADDR,KSMCHCLS  from x$ksmsp where rownum <10;
ADDR KSMCHCLS
-------- --------
B6E35EAC freeabl
B6E35E74 freeabl
B6E35E3C freeabl
B6E35E04 recr
B6E35DCC recr
B6E35D94 recr
B6E35D5C freeabl
B6E35D24 freeabl
B6E35CEC freeabl
 
Shared pool中chunk的分配
1、shared pool中的chunk的大小是不一样的，但是肯定是连续的
2、因为chunk是分配的最小单元，因此session需要给对象分配空间的时候，会以chunk为单位进行申请
3、可用的chunk（free）会形成一个链表（free list，这个free list我们通常叫他bucket），便于进行分配的时候，可以通过遍历链表寻找到可用的适合的chunk，链表是chunk进行组织和管理的一种方式
4、一个可用的chunk链表是一个bucket，shared pool中会有很多的bucket，不同的bucket中的chunk的大小不同，一般是随着bucket编号的增加，bucket的大小是增长的
5、当需要从shared pool中寻找chunk的时候，首先会定位一个bucket（这个bucket有点特殊，session会优先定位和符合自己大小的bucket），然后向下遍历bucket，寻找最合适的chunk
如果chunk的空间比需要的空间大，那么这个chunk就拆分成两个，一个被分配、一个成为free，重新挂接到这个bucket上。
6、在寻找chunk的过程中，如果一个bucket中没有合适的chunk，接着寻找另外一个非空的bucket（在每一个bucket上寻找chunk都是从最小chunk开始），如果所有的bucket中都没有合适的chunk，那么就从rec类型的链表中释放一部分的空间。记住只有recreatetable可以被释放。
如果rec中还找不到那就会出现ORA-4013错误。
7、shared pool中所有类型的chunk都是以链表的方式进行管理的
 
对于上面第4点，我通过抓取trace内存块分析一下，只做简单分析，之后会回trace文件：
 alter session set events 'immediate trace  name heapdump level 2';
你的转储文件在 udump 目录下.根据日期和时间来查找,也可以根据进程号码来查找.以后再介绍.
这个文件是当前内存的信息，信息量巨大，下面只摘取我们需要的内容。
之前见到的chunk类型分布
HEAP DUMP heap name="sga heap(1,0)"  desc=0x2001a948
 extent sz=0xfc4 alt=108 het=32767 rec=9 flg=-126 opc=0
 parent=(nil) owner=(nil) nex=(nil) xsz=0x400000
EXTENT 0 addr=0x3cc00000
  Chunk 3cc00038 sz=       24  R-freeable  "reserved stoppe"
  Chunk 3cc00050 sz=   212888  R-free      "               "
  Chunk 3cc33fe8 sz=       24  R-freeable  "reserved stoppe"
  Chunk 3cc34000 sz=  3975024    perm      "perm           "  alo=3975024
  Chunk 3cffe770 sz=     4064    perm      "perm           "  alo=4064
  Chunk 3cfff750 sz=     2224    free      "               "
EXTENT 1 addr=0x3d000000
  Chunk 3d000038 sz=       24  R-freeable  "reserved stoppe"
  Chunk 3d000050 sz=   212888  R-free      "               "
  Chunk 3d033fe8 sz=       24  R-freeable  "reserved stoppe"
  Chunk 3d034000 sz=  2097168    perm      "perm           "  alo=2097168
  Chunk 3d234010 sz=  1883412    perm      "perm           "  alo=1883412
  Chunk 3d3ffd24 sz=      732    free      "               "
 
第4点中我们说到的free list也就是bucket
Total heap size    = 50330976
FREE LISTS:  ---------千万别把这个FREE LIST和bucket混淆，这个只是trace文件的标示。方便阅读下面有哪个bucket，bucket才是第4点中讲的free list。
 Bucket 0 size=16
 Bucket 1 size=20
 Bucket 2 size=24
 Bucket 3 size=28
 Bucket 4 size=32
 Bucket 5 size=36
 Bucket 6 size=40
 Bucket 7 size=44
 Bucket 8 size=48
 Bucket 9 size=52
 Bucket 10 size=56
 Bucket 11 size=60
 Bucket 12 size=64
 Bucket 13 size=68
  Chunk 3effffbc sz=       68    free      "               "-----第5点中提到的chunk的拆分
 Bucket 14 size=72
 Bucket 15 size=76
 Bucket 16 size=80
 Bucket 17 size=84
 Bucket 18 size=88
 Bucket 19 size=92
 Bucket 20 size=96
 Bucket 21 size=100
 Bucket 22 size=104
 Bucket 23 size=108
 Bucket 24 size=112
 Bucket 25 size=116
 Bucket 26 size=120
 Bucket 27 size=124
 Bucket 28 size=128
 Bucket 29 size=132
 Bucket 30 size=136
 Bucket 31 size=140
 Bucket 32 size=144
 Bucket 33 size=148
 Bucket 34 size=152
 Bucket 35 size=156
 Bucket 36 size=160
 Bucket 37 size=164
 Bucket 38 size=168
 Bucket 39 size=172
 Bucket 40 size=176
 Bucket 41 size=180
 Bucket 42 size=184
 Bucket 43 size=188
 Bucket 44 size=192
 Bucket 45 size=196
 Bucket 46 size=200
 Bucket 47 size=204
 Bucket 48 size=208
 Bucket 49 size=212
 Bucket 50 size=216
 Bucket 51 size=220
 Bucket 52 size=224
 Bucket 53 size=228
 Bucket 54 size=232
 Bucket 55 size=236
 Bucket 56 size=240
 Bucket 57 size=244
 Bucket 58 size=248
 Bucket 59 size=252
 Bucket 60 size=256
 Bucket 61 size=260
 Bucket 62 size=264
 Bucket 63 size=268
 Bucket 64 size=272
 Bucket 65 size=276
 Bucket 66 size=280
 Bucket 67 size=284
 Bucket 68 size=288
 Bucket 69 size=292
 Bucket 70 size=296
 Bucket 71 size=300
 Bucket 72 size=304
 Bucket 73 size=308
 Bucket 74 size=312
 Bucket 75 size=316
  Chunk 3dfffec4 sz=      316    free      "               "
 Bucket 76 size=320
 Bucket 77 size=324
 Bucket 78 size=328
 Bucket 79 size=332
 Bucket 80 size=336
 Bucket 81 size=340
 Bucket 82 size=344
 Bucket 83 size=348
 Bucket 84 size=352
 Bucket 85 size=356
 Bucket 86 size=360
 Bucket 87 size=364
 Bucket 88 size=368
 
经典错误赏析：
ORA-4013
当某个chunk正在被使用时（可能是用户正在使用，也可能是使用了dbms_shared_pool包将对象钉在shared pool里），该chunk是不能被移出内存的。
比如某个SQL语句正在执行，那么该SQL语句所对应的游标对象是不能被移出内存的，该SQL语句所引用的表、索引等对象所占用的chunk也是不能被移出内存的。
当shared pool中无法找到足够大小的所需内存时，报ORA-4031错。
当出现4031错的时候，你查询v$sgastat里可用的shared pool空间时，可能会发现name为“free memory”的可用内存还足够大，但是为何还是会报4031错呢？
事实上，在oracle发出4031错之前，已经释放了不少recreatable类型的chunk了，因此会产生不少可用内存。但是这些可用chunk中，没有一个chunk是能够以连续的物理内存提供所需要的内存空间的，从而才会发出4031的错。
 
shared pool latch的争用问题
只有rec类型的chunk能够被释放空间，即使释放了空间，这些空间可能都不是连续的，都是一些很小的chunk，这样可能形成这样一种情况，shared pool中是大量的非常小的chunk，
这样在寻找chunk的时候，也很难寻找到合适的chunk，同时因为free chunk数量非常的多，因此在分配chunk的时候，就会占用大量的时间，
因为对bucket进行扫描、管理、分配的时候，需要获得shared pool latch，如果小的chunk太多，在扫描free chunk的时候，shared pool latch会被锁定很长的时间，占用太多的时间，自然会发生latch争用的情况，原因就是因为大量的小的free chunk的情况
注意：如果在shared pool中出现了大量的小的free chunk，就会出现share pool latch争用的情况，
而如果增加shared pool尺寸的话，仅仅是延缓shared pool latch的争用，而到最后，就会因为小的free chunks的数量越来越多，争用也会越来越严重。
而到了9i以后，由于大大增加了可用chunk链表（也就是bucket）的数量，同时，每个bucket所管理的可用chunk的尺寸递增的幅度非常小，于是就可以有效的将可用的chunk都均匀的分布在所有的bucket上。这样的结果就是每个bucket上所挂的free类型的chunk都不多，所以在查找可用chunk而持有shared pool latch的时间也可以缩短很多。
 
 
 
 
shared pool对于大对象的处理
对于非常大的对象，oracle会为它们单独从保留区域里分配空间，而不是从这个可用chunk链表中来分配空间。
这部分空间的大小尺寸就是由初始化参数shared_pool_reserved_size决定的，缺省为shared_pool_size的5%，
这块保留区域与正常的chunk的管理是完全分开的，小的chunk不会进入这块保留区域，而这块保留区域的可用chunk也不会挂在bucket上。
这块保留区域的使用情况可以从视图v$shared_pool_reserved中看到，通常来说，该视图的request_misses字段显示了需要从保留区域的可用链表上上获得大的chunk而不能获得的次数，该字段应该尽量为0， 如果大于零，需要增加此区域大小。
通俗的说这块区域是session全部bucket都找不到以后，被逼急了才来这里找，但是这块空间就想武术里面的七伤拳，每取一次都自伤一次。所以就算加大了这块空间，这只是暂时解决问题，需要从业务逻辑才上可以根本解决问题。
SQL> select REQUEST_MISSES from v$shared_pool_reserved;
 
REQUEST_MISSES
--------------
    0
 
Shared Pool的内存结构 （逻辑结构）
 
从一个逻辑层面来看，shared pool由library cache和dictionary cache组成。shared pool中组件之间的关系可以用下图一来表示。
从下面这个图中可以看到，当SQL语句（select object_id,object_name from sharedpool_test）进入library cache时，
oracle会到dictionary cache中去找与sharedpool_test表有关的数据字典信息，比如表名、表的列等，以及用户权限等信息。
如果发现dictionary cache中没有这些信息，则会将system表空间里的数据字典信息调入buffer cache内存，读取内存数据块里的数据字典内容，
然后将这些读取出来的数据字典内容按照行的形式放入dictionary cache里，从而构造出dc_tables之类的对象。
然后，再从dictionary cache中的行数据中取出有关的列信息放入library cache中。 
 
 
 

 library cache 和dictionary cache概述
library cache最主要的功能就是存放用户提交的SQL语句、SQL语句相关的解析树（解析树也就是对SQL语句中所涉及到的所有对象的展现）、执行计划、用户提交的PL/SQL程序块（包括匿名程序块、存储过程、包、函数等）以及它们转换后能够被oracle执行的代码等。
为了对这些内存结构进行管理，还存放了很多控制结构，包括lock、pin、dependency table（从属表）等。
 library cache还存放了很多的数据库对象的信息，包括表、索引等等。有关这些数据库对象的信息都是从dictionary cache中获得的。
如果用户对library cache中的对象信息进行了修改，则这些修改会返回到dictionary cache中。
 
在library cache中存放的所有的信息单元都叫做对象（object），这些对象可以分成两类：
一类叫存储对象，也就是上面所说的数据库对象。它们是通过显式的SQL语句或PL/SQL程序创建出来的，如果要删除它们，也必须通过显示的SQL命令进行删除。这类对象包括表、视图、索引、包、函数等等；（上图中的×××区域）
另一类叫做过渡对象，也就是上面所说的用户提交的SQL语句或者提交的PL/SQL程序块等。这些过渡对象是在执行SQL语句或PL/SQL程序的过程中产生的，并缓存在内存里。如果实例关闭则删除，或者由于内存不足而被交换出去，从而被删除。（上图中的红色区域）
 
父子游标
当用户提交SQL语句或PL/SQL程序块到oracle的shared pool以后，在library cache中生成的一个可执行的对象，这个对象就叫做游标（cursor）。
不要把这里的游标与标准SQL（ANSI SQL）的游标混淆起来了，标准SQL的游标是指返回多条记录的SQL形式，需要定义、打开、关闭。
下面所说到的游标如无特别说明，都是指library cache中的可执行的对象。
游标是可以被所有进程共享的，也就是说如果100个进程都执行相同的SQL语句，那么这100个进程都可以同时使用该SQL语句所产生的游标，从而节省了内存。
每个游标都是由library cache中的两个或多个对象所体现的，至少两个对象。
一个对象叫做父游标（parent cursor），包含游标的名称以及其他独立于提交用户的信息。从v$sqlarea视图里看到的都是有关父游标的信息；v$sqlarea中VERSION_COUNT字段是表示父子关系的子游标v$sql(子游标具体信息)是没有这个字段的
另外一个或多个对象叫做子游标（child cursors），如果SQL文本相同，但是可能提交SQL语句的用户不同，或者用户提交的SQL语句所涉及到的对象为同名词等，都有可能生成不同的子游标。
因为这些SQL语句的文本虽然完全一样，但是上下文环境却不一样，因此这样的SQL语句不是一个可执行的对象，必须细化为多个子游标后才能够执行。子游标含有执行计划或者PL/SQL对象的程序代码块等。 
子游标可以通过v$sql查看。
 
父游标里面包含的信息包括SQL文本和优化目标
session打开该游标以后，就会锁定父游标
所有的session都关闭该游标以后，锁定才能够释放
父游标在被锁定的时候，不能被交换出内存
父游标交换出内存、子游标也会被交换出内存
子游标被交换出内存、父游标可以不被交换出内存
因为一个父游标可能会有多个子游标
子游标包换所有的信息：执行计划、绑定变量等
子游标随时可能被交换出内存
Oracle根据父游标的信息可以构建出一个子游标，这个过程叫reload
 
Hash 算法
Oracle在内部管理中大量的使用到了hash
1、使用hash的目的就是为了快速查找和定位
对数值进行hash运算，产生一个索引号，然后根据索引号将数值放置到相应的hash bucket中去
根据hash运算的法则，会产生多个索引号，每一个索引号对应一个hash bucket（一个数值列）
我们在寻找数值的时候，将搜寻的数值进行hash，产生一个索引号，那么这个数值一定在这个索引号对应的 hash bucket中，于是直接跳转到这个hash bucket中进行遍历。这样我们定位数据的时候，就能够大大的减少遍历的数量。
 
举例：
1.假设我们的数值列表最多可以有10个元素，也就是有10个hash buckets，每个元素最多可以包含20个数值。
2.则对应的二维数组就是t[10][20]。我们可以定义hash算法为n MOD 10。
3.通过这种算法，可以将所有进入的数据均匀放在10个hash bucket里面，hash bucket编号从0到9。
4.我们把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就可以了
 
库缓存中就是使用hash bucket来管理的
1、首先根据shared_pool_size指定的尺寸来自动计算hash bucket的个数
2、每个hash bucket后面都串连着多个句柄（该句柄叫做library cache object handle），这些句柄描述了library cache里的对象的一些属性，包括名称、标记、指向对象所处的内存地址的指针等。可以用下图来描述library cache的整体结构
 
 

 注意：hash bucket就是一个索引号，通过hash bucket对所有的对象进行了分类，分成多个对象链条
在寻找对象的时候，首先根据hash 函数计算出索引号，一定会进入一个hash bucket中
在hash bucket后面是一些句柄，句柄里面是具体的信息，这些信息没有经过hash计算，通过遍历这些句柄，如果对象在这个bucket上，那么就找到，否则说明对象没有在shared pool中，需要创建一个对象，同时将句柄挂接到这个hash bucket上
在寻找对象的时候，可能发现句柄在，但是对象却被换出了内存，怎么办？很简单，将对象重新加载到内存就可以了
可以使用下面的方式来确定reload的比率： 
SQL> select 100*sum(RELOADS)/sum(PINS) RELOAD from v$librarycache;
 
    RELOAD
----------
.973957894
 
我们可以通过查询v$db_object_cache来显示library cache中有哪些对象被缓存，以及这些对象的大小尺寸。
比如，我们可以用下面的SQL语句来显示每个namespace中，大小尺寸排在前3名的对象： 
select *
from (select row_number() over(partition by namespace order by sharable_mem desc) size_rank,
namespace,
sharable_mem,
substr(name, 1, 50) name
from v$db_object_cache
order by sharable_mem desc)
where size_rank <= 3
order by namespace, size_rank
/
 
 
 
 
 
当一条SQL语句进入library cache的时候，
先将SQL文本转化为对应ASCII数值，然后对该这些ASCII数值进行hash函数的运算，
传入函数的是SQL语句的名称（name，对于SQL语句来说其name就是SQL语句的文本）以及命名空间（namespace，对于SQL语句来说是“SQL AREA”，表示共享游标。可以从视图v$librarycache里找到所有的namespace）。
运用hash函数后得到一个值，该值就是hash bucket的号码，从而该SQL语句被分配到该号的hash bucket里去。
实际上，hash bucket就是通过串连起来的对象句柄才体现出来的，它本身是一个逻辑上的概念，是一个逻辑组，而不像对象是一个具体的实体。
oracle根据shared_pool_size所指定的shared pool尺寸自动计算hash buckets的个数，shared pool越大，则可以挂载的对象句柄就越多。
当某个进程需要处理某个对象时，比如处理一条新进入的SQL语句时，它会对该SQL语句应用hash函数算法，以决定其所在的hash bucket的编号，
然后进入该hash bucket进行扫描并比较。有可能会发生该对象的句柄存在，但是句柄所指向的对象已经被交换出内存的情况出现。
这时对应的对象必须被再次装载（reload）。也可能该对象的句柄都不存在，这时进程必须重新构建一个对象句柄挂到hash bucket上，然后再重新装载对象。
SQL语句相关的对象有很多（最直观的就是SQL语句的文本），这些对象都存放在library cache里，它们都通过句柄来访问。
可以把library cache理解为一本书，而SQL语句的对象就是书中的页，而句柄就是目录，通过目录可以快速定位到指定内容的页。
 
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 rows selected.