https://www.oracle.com/technetwork/database/manageability/ps-s003-274003-106-1-fin-v2-128827.pdf

v$sgastat ；

row cache: The dictionary cache -cached rows fro data dictionary used to build more complex sql and library cache objects;

v$db_object_cache(v$sql或者v$sqlarea) 建议用v$sqlstats。降低数据库性能影响

堆的数量取决于对象的类型：一个sql游标有两个heads。一个小的heap是库缓存结果，大的heap为

游标的可执行。（叫sqlarea） ：session_cached_cursors;

oracle需要连续的空间去满足每个内存的请求。

ora-4031是在堆管理器尝试释放所有的可用空间之后造成的。 这些空闲内存都不能产生足够大的连续区段来满足当前的请求。

请注意，共享池中的对象在使用时不能被释放。对于SQL和PL/SQL，这意味着当前执行的任何游标或包都不会过期。当表和索引元数据被用于构建游标或包时，或者当它参与DDI时，不能释放它。同样的原理也适用于行缓存项。共享池中不能老化的对象通常称为“固定的”。

我们前面提到过，共享池对象通常由许多单独的内存分配组成，称为块。为了使分配和释放内存的过程尽可能高效，许多这些块都按照选定的一些分配大小进行标准化。目前使用的最普遍的内存分配单位是1K和4K，尽管还有许多更小的分配单位，例如行缓存。

共享池中的一小部分内存分配将超过4K。这些更大的分配可能会导致问题，因为Oracle可能释放数百个对象，但永远得不到足够大的数据来满足请求。“为了解决这个问题，将留出共享池的一块区域，只用于4K以上的分配;这称为预留池，默认情况下我占用了共享池大小的5%。注意:大分配并不等同于大对象!一个大对象可能完全由4K分配组成，并且从不触及预留池。还要注意，只有在以下情况下才会使用预留池． 共享池中可用空间不足;如果空间可用，那么从普通池中进行大量分配是完全可以接受的。一个在10g数据库中可以看到的大型连续分配的例子是在每个会话开始时分配的“会话参数值”内存。这些分配可能高达30K，通常是从预留池中分配的。如果有人收到这样一个分配的ORA-4031错误信号，解决方案通常是增加预留池的大小，以容纳更多、更大的分配。

所有SQL游标和PL/SQL包几乎全部以4K块分配。游标越大，我们分配给它的4K块就越多;但很少超过4K，除非有一些不寻常的需求需要由SQL优化器或PISQL运行时引擎满足。由于大多数分配请求是为4K块发出的，因此所有释放的游标也将把4K块返回到池中。因此，如果存在可以老化的旧游标或包，那么构建新游标或PL/SQL包就永远不会有问题。

由于我们讨论的是SQL和PL/SOL的内存分配问题，因此也有必要讨论解析问题，因为如果没有硬解析，就很少需要从共享池中分配空间!

硬解析在几个层次上影响系统。即使在构建游标之前，也必须解析和优化SQL。这个过程需要访问库缓存和行缓存资源，可能会导致库缓存和行缓存对象的递归加载。这给库缓存、行缓存和共享池组件带来了压力，并解释了为什么这些系统的高硬解析率经常伴随着闩锁争用。

软解析相对于硬解析的相对代价要小几个数量级，然而，即使是软解析也不是没有代价的。特别是，在共享池中查找SQL语句以及执行游标所需的锁和引脚操作都会引起锁存开销。此外，尽管软解析的成本少了几个数量级，但频率往往多了几个数量级。这就是为什么在客户机和服务器端都引入了各种SQL缓存选项，以帮助在高吞吐量系统上实现可伸缩性。

共享池资源最有效的使用是解析一次，执行多次;这样就避免了解析开销。新的应用程序应该在编码时考虑到最优的资源使用情况，以实现最大的可伸缩性

 

绑定变量：sql语句：

v$sqlarea中，可以查看相同的执行计划，plan_hash_value 但是不同的sql id

或者从v$sqlarea中找到sql text看下sql语句

例如，下面来自AWR报告的时间模型数据表明，大部分时间用于执行SQL语句(98%)，但只有很少的时间用于执行与解析相关的操作(2.5%):

statistic name:

sql execute elapsed time 98.7

parse time elapsed 2.5%

 

shared pool发生的问题：

ora-4031

library cache lock and pin contention (high library cache roloads)

row cache enqueue contention (high row cache reloads)

latch contention (shared pool,library cache,row cache)

ORA-04031共享池内存不足

库缓存锁和引脚争用(高库缓存重载)

行缓存排队争用(重装高行缓存)

锁存争用(共享池、库缓存、行缓存)

 

4030:user_dump_dest

library cache reloads:避免重载，对象失效

select namespace,pins,pins-pinhits loads ,reloads,invalidations ,100*(reloads-invalidations)/(pins-pinhits) "%reloads" from v%librarycache where pins>0 order by namespace;

row cache misses : dictionary cache misses:

select parameter ,sum(gets) gets,sum(getmisses) getmisses,sum("count") num,sum(usage) usage from v$rowcache where getmisses>0 group by parameter order by parameter;

latch contention:

这些问题包括非常高的硬解析率、异常高的软解析和执行率、过度的共享池监控活动和非标准的初始化。

corrective actions:

纠正措施对于4031个错误，最明显的纠正措施是增加共享池的大小。视图V$SHARED POOL建议在推荐最佳共享池大小时可能有用，以避免重新加载。如前所述，如果4031错误的原因是一个较大的分配(大于4K)，那么纠正措施应该是增加预留池。如果不可能增加共享池的大小，那么还有其他解决方案可以减轻共享池的空间压力。例如， 把驻留在共享池中的所有PL/SQL包移走。大量设置session_cached_cursor和使用cursor_space_for_time也会增加空间压力。考虑是否可以减少会话游标缓存的设置值，以及您的站点是否需要cursor_space_for_time(特别是在10.2.0.2中使用互斥时)。

查看共享池是否太大，查看单次执行的sql占比。10%-30%就还可以。

select count(1) num_sql ,sum(decode(executions,1,10)) num_1_use_sql,sum(shareble_mem)/1024/1024 mb_sql_mem,sum(decode(executions,1,sharable_mem,0))/1024/1024 mb_1_use_sql_mem from v$sqlarea where sharable_mem>0;