shared pool 内存块组成

最容易出问题的就是 library cache、free，row cache 一般不出问题

只能设置 shared pool 的总体大小，不能单独设置row cache 和library cache大小 ，Oracle根据实际使用情况 自动设置使用大小

一、free空间

是一个一个小的内存块，使用链(chain)将空闲内存块链起来：

（每个链上所挂的内存块大小是不一样的）

例如 硬解析了一个sql语句，需要根据解析的sql语句和sql语句的执行计划，它所需要占用的实际内存空间，从相应链上找空间存放。

假设需要10k的空间，那么就会从8k那条链找到一个11k的空间

什么时候需要从free空间找chunk：硬解析

硬解析需要内存空间，根据实际大小从free内存空间中的链中找到相应大小内存块使用。会产生小内存块（小chunk），也就是内存碎片

系统如果有大量硬解析的话，虽然free里面还有很多空间，但是所有空间都是小的，并不能使用。

所以可能出现free中还有200m，但是一个sql发生硬解析，去找free chain，却找不到合适大小chain，找不到足够空间，sql语句这时候就会硬解析失败

ORA-4031错误：

1、大量硬解析

2、大量硬解析，产生大量小碎片以后突然又遇到大sql语句（长sql语句）

free 链(chain)

每条链存大小不同的chunk，例如1k、4-8k、8-12k、12k .. 以上

1、把需要组织的内存块（功能或者是特效类似的内存块）串起来

2、链可以遍历（有头有尾）

附：Oracle 数据库的内存结构最重要的特征就是使用了大量的链，使用latch锁对链进行保护

二、Library cache空间

library cache 里面也有很多链，链下挂有很多chunk，但是chunk里面都写了内容（sql、plan执行计划）

根据什么把不同的chunk写上内容后挂在不同链上：

把sql语句所有的字母转换成ASCII码值，就成了数字，然后对这一堆数字进行运算，得到一个数字，再经过运算，就是链的编号，这个sql语句就挂到所对应的编号上。例如得到链的编号是5。

当再次执行sql语句的时候（这个sql语句在library cache里面已经有了）oracle 继续对sql进行运算，得出链的编号，例如链的编号是5。因为5号链已经挂有很多chunk，那么Oracle会锁住这个链，然后进行遍历，一个个找，最后找到这个sql对应chunk，接着就不会发生硬解析了，就变成了软解析。

library cache 也是使用链来组织和管理chunk，但是管理不是以chunk大小来串起来，而是以chunk所对应sql的ASCII码值，运算以后得到的数字挂到相应链上来进行组织管理。

有链就有latch，有shared pool latch、library latch、row cache latch（row cache 也是以链的方式组织管理的）

shared pool 里面的每一个chunk，在x$ksmsp表中都有一行信息

chunk总算（通过x表）：

SQL> select count(*) from x$ksmsp;

COUNT(*)

----------

20033

SQL> select count(*) from dba_indexes;

COUNT(*)

----------

4823

SQL> select count(*) from x$ksmsp;

COUNT(*)

----------

20138

执行select count(*) from dba_indexes; 发生硬解析了，所以chunk有变化

判断软、硬解析

SQL> select name,value from v$sysstat where name like 'parse%';

NAME VALUE

---------------------------------------------------------------- ----------

parse time cpu 88

parse time elapsed 84

parse count (total) 7113

parse count (hard) 937

parse count (failures) 6

parse count (describe) 0

已选择6行。

SQL>

flush命令

将library cache、row cache所有内容全部情空，之后执行所有语句都会进行硬解析

SQL> alter system flush shared_pool;

系统已更改。

SQL>

执行完了之后 ora-4031错误会变少，因为library cache、row cache所有内容全部清空， chunk全部回到free上，free上有大量的chunk，但是接下来会产生大量的硬解析。