第一种错误的原因很明显：分配给共享池的内存不敷以称心用户恳求。（在某些情状下，原因可能不是池自己的大小，而是未利用绑定变量招致的过多阐发形成的碎片，那是我很喜好的一个主题；但目前让我们把重点放在手头的问题上。）其它的错误别离来自卑型池和 Java 池的空间不敷。
您需要处理那些错误情状，而不做任何与利用法式相关的修改。那么有哪些计划可选呢？问题是若何在 Oracle 例程所需的所有池之间划分可用的内存。 馅饼怎么分？ 正如您所领会的，一个 Oracle 例程的系统全局区域 (SGA) 包罗几个内存区域（包罗缓冲高速缓存、共享池、Java 池、大型池和重做日记缓冲）。
那些池在操做系统的内存空间中占据了固定的内存数；它们的大小由 DBA 在初始化参数文件中指定。 那四个池（数据库块缓冲高速缓存、共享池、Java 池和大型池）几乎占据了 SGA 中所有的空间。（与其它区域比拟，重做日记缓冲没有占据几空间，对我们那里的讨论无关紧要。
）做为 DBA，您必需确保它们各自的内存分配是充沛的。 假定您决定了那些池的值别离是 2GB、1GB、1GB 和 1GB。您将设置以下初始化参数来为数据库例程规定池的大小。
db_cache_size = 2g
shared_pool_size = 1g
large_pool_size = 1g
java_pool_size = 1g
如今，认真看一下那些参数。
爽快讲，那些值能否准确？我相信您必然会有疑虑。在现实中，没有人可以为那些池指定切当的内存数 — 它们太依靠于数据库内部的处置，而处置的特征随时在改变。 下面是一个示例场景。假定您有一个典型的、大部门属于 OLTP 的数据库，而且为缓冲高速缓存分配的公用内存比为纯 OLTP 数据库（如今已经很少见了）分配的要少。
有一天，您的用户铺开了一些十分大的全表扫描，以创建当天的完毕报表。Oracle9i 数据库为您供给了在线修改内存分配的功用，但因为供给的总物理内存有限，您决定从大型池和 Java 池中取出一些内存：
alter system set db_cache_size = 3g scope=memory;
alter system set large_pool_size = 512m scope=memory;
alter system set java_pool_size = 512m scope=memory;
那个处理计划可以很好地工做一段时间，但是接着夜间的 RMAN 功课（它们利用大型池）起头了，大型池将立即呈现内存不敷。
同样，您从数据库高速缓存中取出一些内存来填补大型池，以挽救那种场面。 RMAN 功课完成，然后启动一个普遍利用 Java 的批处置法式，接着您起头看到与 Java 池相关的错误。因而，您（再次）从头分配池，以称心 Java 池和数据库高速缓存上的内存需求：
alter system set db_cache_size = 2G scope=memory;
alter system set large_pool_size = 512M scope=memory;
alter system set java_pool_size = 1。
5G scope=memory;。