oracle11 share pool,转： 关于share pool的作用简单解释

引子：一个错误的出现

ORA-4031 cannot allocate memory of xxxx bytes(share pool)

简单解释：(来源与网上文章，相关数据和使用方法后期查证后一起添加)

该错误是指在共享池当中无法分配xxxx字节的内存。共享池是用于存储应用程序的SQL源代码及其相关解析

代码和执行计划的，如果无法分配内存空间，当然就会影响应用系统。

关于在主机上查看share pool配置大小，请在下面目录中查看

oracle安装目录下oracle_home\admin\db_name\pfile\init.ora

那这个内存分配为什么说跟程序设计有关系呢？关键是在于应用设计当中会不断地临时创建和删除表。那针对这点，我们把Oracle的整个详细过程和原理在这里展示一下：

1、当一个应用程序模块运行的时候必定会产生SQL代码，这里我们假设：

insert into cbjl values(…);

2、当这条SQL命令运行的时候会经过CPU的解析，生成该命令的解析树和执行计划，这些相关的资料会保存在Oracle系统全局区(SGA)的共享池(shared pool)中，每一条命令的信息保存在共享池中都是一块连续的内存空间，我们把这种属于某条特定SQL语句的内存空间称之为“命名空间” (named space)。我们这里把刚才那条insert命令的命名空间暂时称为NS2；

3、如果是另一个人运行同样的这一个应用程序的话，由于SQL代码是相同的，所以Oracle就可以直接调用上面的NS2的内容，不需要CPU在次解析了。这就是共享池的优化作用；

4、但是如果cbjl这张表被删除了的话，也就是说上述insert命令的基表不存在了，那么NS1这块内存空间的资料就变得无效了。就算是重新创建一张同名的表，但是由于系统的内部的对象编号不一样，Oracle也不会认为这前后的两张表是相同的。也就是说这意味着生成了一块内存垃圾。

5、当然Oracle能够重复利用这一块内存区域，当假如有另一条比较简单的SQL语句，它所需要的内存比较小，那么就能够放入这块空间当中，例如这里的NS6；

6、但问题是，我们看到一下这一块空间，由于太小了，它可能根本放不下任何一条SQL语句，这样就产生了一块内存碎片；

除了drop 命令，Truncate命令同样会使这些内存当中的Name space无效。为什么呢？

因为对于一张表或者索引来说，有两种ID号码，一个是对象定义的ID号，Oracle内部叫Object id，另一个是数据对象ID，内部称为data object id。前者是纯粹的对象定义相关的，后者是对应这个对象的存储空间的。Drop命令会使这两种id都删除，而truncate命令会使data object id重建。所以，对于name space来说两种命令都会导致它的无效化。

那就是说如果在业务运行的过程当中，应用系统有很多drop和truncate的话，是必定会不断生成大量的内存碎片。Oracle默认是没有自动的内存整理的功能的，也就是说根据这样的应用程序设计，内存大量的耗费一定。内存用尽是迟早的事。