shared pool 内存块组成
最容易出问题的就是 library cache、free,row cache 一般不出问题
只能设置 shared pool 的总体大小,不能单独设置row cache 和library cache大小 ,Oracle根据实际使用情况 自动设置使用大小
一、free空间
是一个一个小的内存块,使用链(chain)将空闲内存块链起来:
(每个链上所挂的内存块大小是不一样的)
例如 硬解析了一个sql语句,需要根据解析的sql语句和sql语句的执行计划,它所需要占用的实际内存空间,从相应链上找空间存放。
假设需要10k的空间,那么就会从8k那条链找到一个11k的空间
什么时候需要从free空间找chunk:硬解析
硬解析需要内存空间,根据实际大小从free内存空间中的链中找到相应大小内存块使用。会产生小内存块(小chunk),也就是内存碎片
系统如果有大量硬解析的话,虽然free里面还有很多空间,但是所有空间都是小的,并不能使用。
所以可能出现free中还有200m,但是一个sql发生硬解析,去找free chain,却找不到合适大小chain,找不到足够空间,sql语句这时候就会硬解析失败
ORA-4031错误:
1、大量硬解析
2、大量硬解析,产生大量小碎片以后突然又遇到大sql语句(长sql语句)
free 链(chain)
每条链存大小不同的chunk,例如1k、4-8k、8-12k、12k .. 以上
1、把需要组织的内存块(功能或者是特效类似的内存块)串起来
2、链可以遍历(有头有尾)
附:Oracle 数据库的内存结构最重要的特征就是使用了大量的链,使用latch锁对链进行保护
二、Library cache空间
library cache 里面也有很多链,链下挂有很多chunk,但是chunk里面都写了内容(sql、plan执行计划)
根据什么把不同的chunk写上内容后挂在不同链上:
把sql语句所有的字母转换成ASCII码值,就成了数字,然后对这一堆数字进行运算,得到一个数字,再经过运算,就是链的编号,这个sql语句就挂到所对应的编号上。例如得到链的编号是5。
当再次执行sql语句的时候(这个sql语句在library cache里面已经有了)oracle 继续对sql进行运算,得出链的编号,例如链的编号是5。因为5号链已经挂有很多chunk,那么Oracle会锁住这个链,然后进行遍历,一个个找,最后找到这个sql对应chunk,接着就不会发生硬解析了,就变成了软解析。
library cache 也是使用链来组织和管理chunk,但是管理不是以chunk大小来串起来,而是以chunk所对应sql的ASCII码值,运算以后得到的数字挂到相应链上来进行组织管理。
有链就有latch,有shared pool latch、library latch、row cache latch(row cache 也是以链的方式组织管理的)
shared pool 里面的每一个chunk,在x$ksmsp表中都有一行信息
chunk总算(通过x表):
SQL> select count(*) from x$ksmsp;
COUNT(*)
----------
20033
SQL> select count(*) from dba_indexes;
COUNT(*)
----------
4823
SQL> select count(*) from x$ksmsp;
COUNT(*)
----------
20138
执行select count(*) from dba_indexes; 发生硬解析了,所以chunk有变化
判断软、硬解析
SQL> select name,value from v$sysstat where name like 'parse%';
NAME VALUE
---------------------------------------------------------------- ----------
parse time cpu 88
parse time elapsed 84
parse count (total) 7113
parse count (hard) 937
parse count (failures) 6
parse count (describe) 0
已选择6行。
SQL>
flush命令
将library cache、row cache所有内容全部情空,之后执行所有语句都会进行硬解析
SQL> alter system flush shared_pool;
系统已更改。
SQL>
执行完了之后 ora-4031错误会变少,因为library cache、row cache所有内容全部清空, chunk全部回到free上,free上有大量的chunk,但是接下来会产生大量的硬解析。
[@more@]来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29000429/viewspace-1060629/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29000429/viewspace-1060629/