第四讲--shared pool内存块组成结构及4031错误产生原因分析
2016-03-21 19:22
316 查看
我们只能设置shared pool的大小,不能设置里面librarycache和row cache的大小。
Free的内存结构:
![](http://img.blog.csdn.net/20160321191959314?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
Free空间由一个个小的内存块(chunk,图中圆圈)组成,然后用链(chain)把内存块挂到链上。图中所示的三个链由上到下所挂的内存块的大小越来越大。
硬解析时根据SQL执行计划的大小,从free区中分配合适的内存块给执行计划,并把内存块移到library cache里。
假设一种情况:上图由上到下三个链的大小是4K、8K、12K,此时一个执行计划需要10K,那么就从12K的链上取出一块内存,分成两半,一半10K给执行计划,另一半2K挂到更小的链上。
过多的硬解析容易造成碎片,虽然free区有很多空间但是都是小碎片,不能使用。如果SQL找不到合适大小的内存块(chunk),这是会报ORA-4031错误。
ORA-4031错误产生的原因:
1. 大量的硬解析;
2. 大量硬解析产生大量小碎片以后突然又来了一些比较长的SQL语句,长SQL需要大空间,这个时候空间就不够了;
链:可以把内存块串起来;所有的内存块都挂在链上,链可以遍历;oracle大量使用链技术,链由锁(latch)来保护
library cache的内存结构:
![](http://img.blog.csdn.net/20160321192124909?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
跟free一样也是由链组成,但是挂载链上的内存块写的有内容。内容就是SQL语句以及对应的执行计划(plan)。
硬连接发生时,free上的chunk挂到library cache上的过程:
1. SQL语句所有的字母被server process解析成ASCII码值,SQL语句被变成一串数字了;
2. 然后对这一串数字进行运算,得到一个数字,这个数字就是library cache中链的编号;
3. Server process把SQL语句以及对应的执行计划挂到算出编号的链上;
4. 当再次执行这条SQL语句时,server process执行步骤1-2,得到链编号,链上挂着很多chunk,server process用锁(latch)把链锁上,遍历链,找到chunk以后就是软解析了;
查看shared pool里面有多少个chunk:
发生一次硬解析:
然后再查chunk数:
清空library cache和row cache:
清空之后执行任何一条语句都会发生硬解析,同时ORA-4031错误立马减少。
Free的内存结构:
Free空间由一个个小的内存块(chunk,图中圆圈)组成,然后用链(chain)把内存块挂到链上。图中所示的三个链由上到下所挂的内存块的大小越来越大。
硬解析时根据SQL执行计划的大小,从free区中分配合适的内存块给执行计划,并把内存块移到library cache里。
假设一种情况:上图由上到下三个链的大小是4K、8K、12K,此时一个执行计划需要10K,那么就从12K的链上取出一块内存,分成两半,一半10K给执行计划,另一半2K挂到更小的链上。
过多的硬解析容易造成碎片,虽然free区有很多空间但是都是小碎片,不能使用。如果SQL找不到合适大小的内存块(chunk),这是会报ORA-4031错误。
ORA-4031错误产生的原因:
1. 大量的硬解析;
2. 大量硬解析产生大量小碎片以后突然又来了一些比较长的SQL语句,长SQL需要大空间,这个时候空间就不够了;
链:可以把内存块串起来;所有的内存块都挂在链上,链可以遍历;oracle大量使用链技术,链由锁(latch)来保护
library cache的内存结构:
跟free一样也是由链组成,但是挂载链上的内存块写的有内容。内容就是SQL语句以及对应的执行计划(plan)。
硬连接发生时,free上的chunk挂到library cache上的过程:
1. SQL语句所有的字母被server process解析成ASCII码值,SQL语句被变成一串数字了;
2. 然后对这一串数字进行运算,得到一个数字,这个数字就是library cache中链的编号;
3. Server process把SQL语句以及对应的执行计划挂到算出编号的链上;
4. 当再次执行这条SQL语句时,server process执行步骤1-2,得到链编号,链上挂着很多chunk,server process用锁(latch)把链锁上,遍历链,找到chunk以后就是软解析了;
查看shared pool里面有多少个chunk:
SQL> select count(*) from x$ksmsp; COUNT(*) ---------- 21942
发生一次硬解析:
> select count(*) from dba_indexes; COUNT(*) ---------- 2344
然后再查chunk数:
SQL> select count(*) from x$ksmsp; COUNT(*) ---------- 21971
清空library cache和row cache:
<pre name="code" class="sql">SQL> alter system flushshared_pool; System altered.
清空之后执行任何一条语句都会发生硬解析,同时ORA-4031错误立马减少。
相关文章推荐
- JavaScript自学之数组排序
- 上拉/下拉电阻
- Nginx工作原理和优化、漏洞。
- 深入hibernate的三种状态
- rails调试
- Rails插件之ckeditor
- lintcode 求最长公共子串
- CoreData的数据迁移
- 技术菜鸟成长宝典
- Rails插件之byebug
- 自适应宽度的ListView
- ACM—最短路—8月14日
- csdn的markdown 编辑器 不能用了?
- 刘宇凡:解读微信朋友圈策略调整的重要目的
- console对象
- threejs贴图的几个问题
- Core Data Model Versioning and Data Migration Programming Guide
- 纠正一个概念:类就有VMT,各实例不过是共享这个VMT而已
- iOS应用架构谈 组件化方案
- LNMP一键安装包