能不能分析Share Pool为什么老是说不够呢

Question

数据量不大。
我想不是配置有问题就是应用程序有问题，但连接的Session不是很多。
哪位能不能帮我分析一下可能是什么原因呢。
还有在别人机器上，OEM里能看到Session信息页有一列是显示每个连接占用的大小的，我这里怎么没有呢。

Answer 1

现在Shared Pool还是100M, Buffer Cache给300M, 数据库跑两三天就会报Ora-04031错误.
算算我用的还是共享模式阿，怎么会的呢。
问一下用alter system flush shared_pool 命令可以释放SharePool吗？如果可以总比重启服务强。

Answer 2

ORA-04031 错误通常是因为库高速缓冲中或共享池保留空间中的碎片。 在加大共享池大小的时 候考虑调整应用
使用共享的SQL 并且调整如下的参数：SHARED_POOL_SIZE,
SHARED_POOL_RESERVED_SIZE,
SHARED_POOL_RESERVED_MIN_ALLOC.首先判定是否ORA-04031 错误是由共享池保留空间中的库高速缓冲的碎片产生的。提交下的查 询：SELECT free_space, avg_free_size, used_space, avg_used_size,
request_failures, last_failure_size
FROM v$shared_pool_reserved;如果:REQUEST_FAILURES > 0 并且
LAST_FAILURE_SIZE > SHARED_POOL_RESERVED_MIN_ALLOC那么ORA-04031 错误就是因为共享池保留空间缺少连续空间所致。
要解决这个问题,可以考虑加大SHARED_POOL_RESERVED_MIN_ALLOC 来降低缓冲进共 享池保留空间的对
象数目，并增大 SHARED_POOL_RESERVED_SIZE 和SHARED_POOL_SIZE 来加大共享池保留空间的可用
内存。如果：
REQUEST_FAILURES > 0 并且
LAST_FAILURE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC或者REQUEST_FAILURES 等于0 并且
LAST_FAILURE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC那么是因为在库高速缓冲缺少连续空间导致ORA-04031 错误。第一步应该考虑降低SHARED_POOL_RESERVED_MIN_ALLOC 以放入更多的对象到共享池
保留空间中并且加大SHARED_POOL_SIZE。

Answer 3

REQUEST_FAILURES 等于0 而且
LAST_FAILURE_SIZE 也等于0 肯定 < SHARED_POOL_RESERVED_MIN_ALLOC
~Database Version            : Oracle8i Enterprise Edition Release 8.1.7.0.0 
~Database Up Since           : 02:53:50 下午, 3月  25 2005
!Buffer Cache Hit Ratio      : 73.9127
~Library Cache Miss Ratio    : 0.0248
~Dictionary Cache Miss Ratio : 0.0176[Shared Pool Usage] Exec Time 0 seconds
~ Total Mb Unused : 249.1
~ Total Mb Used   : 50.9
~ Total Mb        : 300
~ Shared Pool Percent Used : 16.97
高速缓存击中率较低而且
Shared Pool 的使用率增加比较快

Answer 4

有什么好方法解决
!Buffer Cache Hit Ratio      : 73.9127
Shared Pool 的使用率增加比较快
其中分析Shared Pool池发现sql area 和 library cache增长快

Answer 5

还有!high parse to execute ratio的问题怎么解决我的基本上在160左右啊

Answer 6

要解决这个错误,进行的诊断的第一步是在你的平台上使用最新的补丁集。
大多数的ORA-04031错误都和BUG 相关，可以通过使用这些补丁来避免。和这个错误相关的最常见的BUG有<Bug:1397603>、<Bug:1640583>、<Bug:1318267>、<Bug:1193003> ，最好修补这个问题。
共享池碎片
每一次，需要被执行的SQL 或者PL/SQL 语句的解析形式载入共享池中都需要一块特定的连续
的空间。数据库要扫描的第一个资源就是共享池中的空闲可用内存。一旦空闲内存耗尽，数据库
要查找一块已经分配但还没使用的内存准备重用。如果这样的确切尺寸的大块内存不可用，就继
续按照如下标准寻找：◇ 大块(chunk)大小比请求的大小大
◇ 空间是连续的
◇ 大块内存是可用的(而不是正在使用的)这样大块的内存被分开，剩余的添加到相应的空闲空间列表中。当数据库以这种方式操作一段时
间之后，共享池结构就会出现碎片。当共享池存在碎片的问题,分配一片空闲的空间就会花费更多的时间,数据库性能也会下降(整个操
作的过程中，"chunk allocation"被一个叫做"shared pool latch" 的闩所控制) 或者是出现
ORA-04031 错误errors (在数据库不能找到一个连续的空闲内存块的时候)。如果SHARED_POOL_SIZE 足够大，大多数的 ORA-04031 错误都是由共享池中的动态SQL
碎片导致的。可能的原因如下：◇非共享的SQL
◇生成不必要的解析调用 (软解析)
◇没有使用绑定变量要减少碎片的产生你需要确定是前面描叙的几种可能的因素。可以采取如下的一些方法，当然不
只局限于这几种: 应用调整、数据库调整或者实例参数调整。

Answer 7

下面的视图有助于你标明共享池中非共享的SQL/PLSQL：V$SQLAREA 视图这个视图保存了在数据库中执行的SQL 语句和PL/SQL 块的信息。下面的SQL 语句可以
显示给你带有literal 的语句或者是带有绑定变量的语句：SELECT substr(sql_text,1,40) "SQL", count(*) , sum(executions) "TotExecs"
FROM v$sqlarea
WHERE executions < 5
GROUP BY substr(sql_text,1,40)
HAVING count(*) > 30
ORDER BY 2;注意: 语句Having 中的 "30"数值可以根据需要调整以得到更为详细的信息。X$KSMLRU 视图有一个固定表x$ksmlru 跟踪共享池中导致其它对象换出(age out)的应用。这个固定表可
以用来标记是什么导致了大的应用。如果很多对象在共享池中都被阶段性的刷新可能导致响应时间问题并且有可能在对象重载
入共享池中的时候导致库高速缓冲闩竞争问题。关于这个x$ksmlru 表的一个不寻常的地方就是如果有人从表中选取内容这个表的内容就
会被擦除。这样这个固定表只存储曾经发生的最大的分配。这个值在选择后被重新设定这
样接下来的大的分配可以被标记，即使它们不如先前的分配过的大。因为这样的重置，在
查询提交后的结果不可以再次得到，从表中的输出的结果应该小心的保存。
监视这个固定表运行如下操作：

Answer 8

SELECT * FROM X$KSMLRU WHERE ksmlrsiz > 0;在Oracle8i 中这个表不能被SYS用户之外的用户所选取。? 小的共享池尺寸最后,一个小的共享池可以导致ORA-04031 错误, 不过在碎片真正的是个问题的时候增大
共享池的大小的时候要小心。在错误发现的时候通常有延迟现象，不过当在大的共享池的
碎片中找到一片空闲的内存会加大对性能的影响。下面的信息将有助于你调整共享池的大小：库高速缓冲命中率
命中率有助于你衡量共享池的使用，基于多少次SQL/PLSQL 需要被解析而不是
重用。下面的SQL 语句有助于你计算库高速缓冲的命中率：SELECT SUM(PINS) "EXECUTIONS",
SUM(RELOADS) "CACHE MISSES WHILE EXECUTING"
FROM V$LIBRARYCACHE;如果misses 比上executions 大于1%, 那就应该尝试着通过加大共享池来减少库高速缓冲
的丢失。

Answer 9

我通过toad监测shared pool监测其空间使用情况
其中Misc大概使用30m
sql area 大概使用120m
library cache大概使用100m
自由空间剩余的比较少
另我的oracle版本时8.17

Answer 10

Oracle8i Enterprise Edition Release 8.1.7.0.0 - 64bit Production
PL/SQL Release 8.1.7.0.0 - Production
CORE 8.1.7.0.0 Production
TNS for HPUX: Version 8.1.7.0.0 - Development
NLSRTL Version 3.4.1.0.0 - Production