ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Oracle一些参数的理解 cursor_sharing

Oracle一些参数的理解 cursor_sharing

原创 Linux操作系统 作者:sxzhanghl 时间:2009-06-24 12:40:04 0 删除 编辑
参数session_cached_cursors解释
------------------------------------------------
自己一直感觉对oracle的内存这一块儿理解不够深刻。
今天看到关于session_cached_cursors参数的解释。翻译一下。同时也加入一点自己的理解
oracle有一个概念,那就是session cursor cache,中文描述就是有一块内存区域,用来存储关闭了的cursor。当一个cursor关闭之后oracle会检查这个cursor的request次数是否超过3次,如果超过了三次,就会放入session cursor cache,这样在下次parse的时候,就可以从session cursor cache中找到这个statement->Alan其实这里就是把cursor缓存在了PGA里面(private sql area)。session cursor cache的管理也是使用LRU。session_cached_cursors这个参数是控制session cursor cache的大小的。session_cached_cursors定义了session cursor cache中存储的cursor的个数。这个值越大,则会消耗的内存越多
另外检查这个参数是否设置的合理,可以从两个statistic来检查
session cursor cache hits 和parse count(total)就是总的parse次数中,在session cursor cache中找到的次数,所占比例越高,性能越好。如果比例比较低,并且有剩余内存的话,可以考虑加大该参数。

参数shared_pool_reserved_size的解释
--------------------------------------------------------
这个参数设置的目的是为了保证大对象在内存中的装载.Alan:因为shared_pool中的chunk都是以4k为基准的,使用于小的内存块,同时也是基于LRU的管理
对于shared pool,oracle是以chunk的方式来分配内存的。当请求一个大内存的时候,oracle可以将这个请求分成几个小的chunk,来装载这个大对象。但是还是有一些内存请求操作,比如编译plsql 过程或者函数的时候,需要大的内存,但是这时候shared pool中没有了空闲的内存可以使用,这时候就会使用shared_pool_reserved_size
当有大对象需要装载到内存时,oracle查找位置的方式是首先在unreserved shared pool中查找,如果有内存可以使用,就在unreserved pool中分配,如果unreserved 中没有足够的内存,就是使用reserved shared pool来装载这个大对象。
当unreserved shared pool和reserved shared pool都不能满足的时候,oracle就会free 内存,就是释放内存,在释放内存后,oracle再按照上面的顺序区查找。
一般情况下,shared_pool_reserved_size是不需要调整的。尤其是现在内存配置如此高的情况下,只要合理的配置shared_pool_size就可以了

有一个视图v$shared_pool_reserved是一个纪录请求reserved shared pool的视图,shared pool调优,目标是调整到这个视图中的request_misses为零,如果这个做不到的话,是要尽量避免request_failures的值持续增大的

参数cursor_sharing的解释
--------------------------------------

这个参数的设置,oracle是为了满足一些以前开发的程序,里面有大量的similar statement,但是重写有不现实的情况下使用的一个参数。
并且oracle也不建议使用这个参数。

什么时候需要修改这个参数呢?需要满足以下的条件。
一个是由于大量的shared pool hit miss影响了用户的响应时间(就是当前的shared pool无法满足共享sql语句存储的需要,Alan:当前libary cache中没有我们所需要重用的explain和sql),如果没有这个问题,那么设置这个参数,可能会造成更糟糕的性能。这个参数只会减少parse的时间。
另外一个就是在现有程序中有大量的similar statement,可以通过设置这个参数来获得比较好的性能。
cursor_sharing这个参数有三个值可选,exact、similar、force。当值为exact时为默认值,也是oracle的默认处理方式。就是当一个statement parse的时候,首先到shared pool区查看是否有exact statement存在(就是看是否在shared pool中有和当前要解析的statement完全一样的语句存在),如果不存在,就执行hard parse
如果该参数设置为similar,那么如果在shared pool中无法找到exact statement的存在的时候,就会在shared pool进行一次新的查找,就是查找和当前要解析的语句是否是similar statement的语句。这里需要对similar statement进行解释,similar statement就是除了value of some literal不同的语句,别的地方都相同的语句。比如下面:

select * from a where a=1;
select * from a where a=2;

当cursor_sharing设置为similar时,如果在shared pool中查找到这样的语句,就会做下一步的检查,看shared pool中缓存的这个语句的execution plan是否适合当前解析的语句,如果适合,就会使用shared pool的语句,而不去做hard parse。如果cursor_sharing设置为force的时候,当在shared pool中发现了similar statement之后,就不会再去检查执行计划了,而直接使用在shared pool的这个语句了。
将cursor_sharing设置为force实际上是危险的。这会可能形成suboptimal的执行计划。比如对于一个范围查找的语句,比如
select * from a where a>10 and a<20这样类型的语句,缓存中的语句的执行计划可能对于正在解析的语句就是不适合的,不是最优的执行计划。
这样看起来是减少了parse恶的时间,但是大大增大了execution的时间。

对于新开发的application,最后是不要设置这个参数,而是针对可以共享的语句使用帮定变量,而对于不适合共享的语句,就不使用帮定变量。将cursor_sharing保持默认值,也就是exact。

调整cursor_sharing的关键一定是要看调整cursor_sharing的条件是否存在。
就是是否有比较大的shared pool hitmis,如果这个条件没有,那就没有必要调整这个参数。cursor_sharing的目的是减少parse time,但是在整个db time中,可能parse time只占很小的一部分。

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

上一篇: histogram与10053(zt)
请登录后发表评论 登录
全部评论

注册时间:2009-03-19

  • 博文量
    31
  • 访问量
    58841