12 shared内存块组成结构及4031错误产生原因分析

shared pool 内存块组成

最容易出问题的就是 library cachefreerow 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,例如1k4-8k8-12k12k .. 以上

1、把需要组织的内存块(功能或者是特效类似的内存块)起来

2、链可以遍历(有头有尾)

附:Oracle 数据库的内存结构最重要的特征就是使用了大量的链,使用latch进行保护

二、Library cache空间

library cache 里面也有很多链,链下挂有很多chunk,但是chunk里面都写了内容(sqlplan执行计划)

根据什么把不同的chunk写上内容后挂在不同链上:

sql语句所有的字母转换成ASCII码值,就成了数字,然后对这一堆数字进行运算,得到一个数字,再经过运算,就是链的编号,这个sql语句就挂到所对应的编号上。例如得到链的编号是5

再次执行sql语句的时候(这个sql语句在library cache里面已经有了oracle 继续对sql进行运算,得出链的编号,例如链的编号是5。因为5号链已经挂有很多chunk,那么Oracle会锁住这个链,然后进行遍历,一个个找,最后找到这个sql对应chunk,接着就不会发生硬解析了,就变成了软解析

library cache 也是使用来组织和管理chunk,但是管理不是以chunk大小来串起来,而是以chunk所对应sqlASCII码值运算以后得到的数字挂到相应链上来进行组织管理。

就有latch,有shared pool latchlibrary latchrow cache latchrow 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 cacherow cache所有内容全部情空,之后执行所有语句都会进行硬解析

SQL> alter system flush shared_pool;

系统已更改。

SQL>

执行完了之后 ora-4031错误会变少,因为library cacherow cache所有内容全部清空, chunk全部回到freefree上有大量的chunk,但是接下来会产生大量的硬解析。

[@more@]

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29000429/viewspace-1060629/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/29000429/viewspace-1060629/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值