shared pool 总结
2013-10-24 23:46
134 查看
两个概念:1、chain 2、chunk
SHARED POOL
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
FREE
这里要引入一个概念:ORA—4031这是一个经典的free空间的报错:
主要的原因就是 free中都是小的chunk,这时候来了一个大的sql语句做硬解析,而free中没有大的chunk了,报ORA—4031
有人问了,为什么free中都是小的chunk了呢?主要是由于大量的硬解析,产生了大量的小的chunk(我们也称之为碎片),产生的过程见上图
这就是为什么我看free还有200M,还会报ORA—4031的原因,因为都是些小的chunk组成了你这200M啊~!!
有的DBA用 alter system flush shared_pool 这条命令去消除4031错误
这样确实能占时消除4031错误,因为library cache链上的chunk被没清空了,回到了free中,free中就有了大的chunk
但是,这是所有的sql都会走硬解析,随着系统的运行,free中的chunk又回到了library cache中,继续产生小的chunk在free中,最后还是可能会报4031错误
治标不治本,蒙蒙甲方还可以。。。。
------------------------------------------------------------------------------------------------------------------------------------------------------------
library cache
select count(*) from x$ksmsp;
---这个字典中每行对应shared_pool中的一个chunk,这条语句查的就是shared_pool中的chunk总数
如果oracle执行了硬解析,那么chunk数就会增加。所以有时候我们可以用这条语句去看一段时间内是否做了大量的硬解析(行数大量增加)
当然我们一般还是用这个语句去看解析的状况:select name,value from v$sysstat where name like 'parse%';
注:我上图中,oracle去5号链上遍历,会把5号链锁住(libaray cache latch),这样的话如果咱们吧shared_pool设的很大,library cache中缓存的sql/执行计划就会很多,链就会很长,那么遍历的时间就长,锁住链的时间就会很长。
SHARED POOL
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
FREE
这里要引入一个概念:ORA—4031这是一个经典的free空间的报错:
主要的原因就是 free中都是小的chunk,这时候来了一个大的sql语句做硬解析,而free中没有大的chunk了,报ORA—4031
有人问了,为什么free中都是小的chunk了呢?主要是由于大量的硬解析,产生了大量的小的chunk(我们也称之为碎片),产生的过程见上图
这就是为什么我看free还有200M,还会报ORA—4031的原因,因为都是些小的chunk组成了你这200M啊~!!
有的DBA用 alter system flush shared_pool 这条命令去消除4031错误
这样确实能占时消除4031错误,因为library cache链上的chunk被没清空了,回到了free中,free中就有了大的chunk
但是,这是所有的sql都会走硬解析,随着系统的运行,free中的chunk又回到了library cache中,继续产生小的chunk在free中,最后还是可能会报4031错误
治标不治本,蒙蒙甲方还可以。。。。
------------------------------------------------------------------------------------------------------------------------------------------------------------
library cache
select count(*) from x$ksmsp;
---这个字典中每行对应shared_pool中的一个chunk,这条语句查的就是shared_pool中的chunk总数
如果oracle执行了硬解析,那么chunk数就会增加。所以有时候我们可以用这条语句去看一段时间内是否做了大量的硬解析(行数大量增加)
当然我们一般还是用这个语句去看解析的状况:select name,value from v$sysstat where name like 'parse%';
注:我上图中,oracle去5号链上遍历,会把5号链锁住(libaray cache latch),这样的话如果咱们吧shared_pool设的很大,library cache中缓存的sql/执行计划就会很多,链就会很长,那么遍历的时间就长,锁住链的时间就会很长。
相关文章推荐
- buffer cache 和shared pool详解(之五,问题诊断总结)
- 数据库开发个人总结(ADO.NET小结)
- java里的中文乱码问题总结。
- C#中的常用正则表达式总结
- 【SSI开发总结.7】Struts+Spring+Ibatis环境配置(二)
- C# webservice调用方法总结
- 以前总结的关于MFC的一些知识
- windows 7 内核程序开发经验总结
- GridView里面的HyperLink和ButtonField操作总结
- source insight的快捷键总结
- 关于-viewWillAppear:等无法调用的总结
- .NET 面试题总结 (附有参考答案) 第1部分
- clistctrl重绘,总结一下,免得又搞忘了,
- 最大流dinic总结模版
- 类似总结的杂谈
- 2013年3月4日小项目问题总结
- Office控件开发总结-构建Office控件
- Android常用控件总结
- android ksoap2调用.net Webservice 方法总结
- 面试总结