这样大块的内存被分开，剩余的添加到相应的空闲空间列表中。当数据库以这种方式操作一段时间之后，共享池结构就会出现碎片。
当共享池存在碎片的问题,分配一片空闲的空间就会花费更多的时间,数据库性能也会下降(整个操作的过程中，"chunk allocation"被一个叫做"shared pool latch" 的闩所控制) 或者是出现 ORA-04031 错误errors (在数据库不能找到一个连续的空闲内存块的时候)。
参考 <61623.1>: 可以得到关于共享池碎片的具体讨论。
假如SHARED_POOL_SIZE 足够大，大多数的 ORA-04031 错误都是由共享池中的动态SQL 碎片导致的。可能的原因如下：
非共享的SQL
生成不必要的解析调用 (软解析)
没有使用绑定变量
要减少碎片的产生你需要确定是前面描叙的几种可能的因素。可以采取如下的一些方法，当然不只局限于这几种: 应用调整、数据库调整或者实例参数调整。
请参考 <62143.1>，描述了所有的这些细节内容。这个注释还包括了共享池如何工作的细节。
下面的视图有助于你标明共享池中非共享的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 表的一个不平常的地方就是假如有人从表中选取内容这个表的内容就会被擦除。这样这个固定表只存储曾经发生的最大的分配。这个值在选择后被重新设定这样接下来的大的分配可以被标记，即使它们不如先前的分配过的大。因为这样的重置，在查询提交后的结果不可以再次得到，从表中的输出的结果应该小心的保存。监视这个固定表运行如下操作：
SELECT * FROM X$KSMLRU WHERE ksmlrsiz > 0;
这个表只可以用SYS用户登录进行查询。
评论加载中…
 |