绑定变量和cursor_sharing：
如果SHARED_POOL_SIZE设置得足够大，又可以排除Bug的因素，那么大多数的ORA-04031错误都是由共享池中的大量SQL代码等导致过多内存碎片引起的。
可能的主要原因有：
·SQL没有足够的共享；
·大量不必要的解析调用；
·没有使用绑定变量。
实际上说，应用的编写和调整始终是最重要的内容，Shared Pool的调整根本上要从应用入手。根本上，使用绑定变量可以充分降低Shared Pool和Library Cache的Latch竞争，从而提高性能。
反复的SQL硬解析不仅会消耗大量的CPU资源，也会占用更多的内存，严重影响数据库性能，而使用绑定变量则可以使S
... ...
<阅读全文>
Shared Pool 的转储与分析：
使用如下命令可以对共享池Library Cache信息进行转储分析：
ALTER SESSION SET EVENTS 'immediate trace name LIBRARY_CACHE level LL';
其中LL代表Level级别，对于9.2.0及以后版本，不同Level含义如下：
·Level=1，转储Library Cache统计信息；
·Level=2，转储Hash Table概要；
·Level=4，转储Library Cache对象，只包含基本信息；
·Level=8，转储Library Cache对象，包含详细信息（如：child references、pin waiters等）；
·Level=16，增加heap sizes信息；
·Level=32，增加heap信息。
... ...
<阅读全文>
了解X$KSMSP视图：
Shared Pool的空间分配和使用情况，可以通过一个内部视图来观察，这个视图就是X$KSMSP（[K]ernal [S]torage [M]emory Management [S]GA Hea[P]），其中每一行都代表着Shared Pool中的一个Chunk。以下是X$KSMSP的结构：
sys@CCDB> desc x$ksmsp
Name Null? Type
------------------------ -------- ----------------
ADDR &n
... ...
<阅读全文>
Oracle 10g 共享池管理的增强：
子缓冲池的分配的算法很简单：
·每个子缓冲池必须满足一定的内存约束；
·每4颗CPU可以分配一个子缓冲池，最多7个。
在Oracle 9i中，每个SubPool至少128MB，在Oracle 10g中，每个子缓冲池至少为265MB。如上篇日志所述，SubPool的数量可以通过_kghdsidx_count参数来控制，但是没有参数可以显示地控制SubPool的大小。
根据以上规则，在一个12颗CPU的系统中，如果分配300MB Shared Pool，Oracle 9i将创建2个SubPool，每个大约150MB，如果共享池增加到500MB，Orac
... ...
<阅读全文>
Oracle 9i 子缓冲池的增强：
从Oracle 9i开始，Shared Pool可以被分割为多个子缓冲池（SubPool）进行管理，每个SubPool可以被看作是一个Mini Shared Pool，拥有自己独立的Free List、内存结构以及LRU List。同时Oracle提供多个Latch对各个子缓冲池进行管理，从而避免单个Latch的竞争（Shared Pool Reserved Area同样进行分割管理）。SubPool最多可以有7个，Shared Pool Latch也从原来的一个增加到现在的7个。如果系统有4个或4个以上的CPU，并且SHARED_POOL_SIZE大于250MB，Oralce可以把Shared Pool分割为多个子缓冲池（SubPool）进行管理，在Oracle 9i中，每个SubPool至少128MB。 以下查询显示的是为管理SubPool而新增的子Latch：... ...
<阅读全文>
Recent Comments