SQL tuning和shared pool结构的关联介绍

影响性能的计算机资源大抵三种：Memory、CPU和I/O。通过调整SGA、PGA充分利用物理MEMORY，通过并行处理充分利用CPU，通过调整I/O

影响性能的计算机资源大抵三种：Memory、CPU和I/O。通过调整SGA、PGA充分利用物理MEMORY，通过并行处理充分利用CPU，通过调整I/O分布充分利用硬盘处理力。

server process和PGA是“一条绳上的两个蚂蚱”，故sp还有个雅号叫“用户体验度进程”。SMON主内，负责整理SGA，如空间碎片；PMON负责外交，检测client process和server process。

shared pool的命中率（hiting）=L/(L+P).L：逻辑读；P：物理读。命中率高不一定没问题，如100w/（100w+10w），10w物理读I/O绝对是个问题。

shared pool的结构主要有：

① free memory ：可用内存

② library cache ：sql、pl/sql、java等代码；执行计划

③ row cache ：数据字典信息

free memory的内存被分割成大小参差的chunk，然后用chain串起，每条chain上所挂的chunk都是不一样的，如chain_A挂了4k，chain_B挂了8k，chain_C挂了12k，现有条sql在parse时，，需10k chunk，则server process会去遍历chain_B，假设找到了11k的chunk，那么有10k chunk用去存该sql的代码和执行计划，1k碎片chunk则被挂到chain_A上。记住了，只有hard parse才需要从free memory遍历chain，确定合适的chunk。这1k碎片会被SMON整理。

从上面的论述，我们也可以知道，Oracle是通过chain来维护shared_pool，这样做的好处：

㈠ 串起内存块

㈡ 可遍历

我们还可以认识到hard parse和soft parse之间的两个最大的不同：

Ⅰ 二者最大，且最严重的区别是，hard parse需要从N条执行方案挑出一条最优的，作为该sql的执行计划

Ⅱ hard parse需要到free memory摘得chunk，填上sql、执行计划，然后挂到library cache

查看hard parse 和 soft parse的个数：

那么从free memory摘到的这10k chunk是如何挂到library cache的呢？server process会将sql、执行计划等，通过一系列的hash 运算，先将他们转化为ASCI码，再hash为一个hash值，这个值便是library cache里某条chain的编号，然后将10kchunk挂上library cache。

shared pool里面的chunk总数：

通过alter system flush可手动改变chunk，具体影响见：alter system flush shared_pool

由此，我们也可得出，对于一条sql语句，可分静态部分和动态部分，其中静态部分对大小写、空格、回车键等统统都是敏感的，否则，在将其通过hash运算成chain编号时会不一致，所以，在开发过程中，统一的编程规范是至关重要的，这可避免减小hard parse。另外，我们也可以使用绑定变量，对sql的动态部分作出选择。

例子：

server process接手一条sql，对它的处理过程，粗劣可分三个步骤：

①  parse ：到shared pool去查看执行计划，决定soft parse还是hard parse

② execute

③ fetch ：到buffer cache里获取需求的数据，决定逻辑I/O还是物理I/O.