参数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。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中找到的次数，所占比例越高，性能越好。如果比例比较低，并且有剩余内存的话，可以考虑加大该参数。

我记着好像是有人讨论过关于soft parse和在cursor cache中命中的区别，我也没有弄明白呢。
上面是自己的理解，有错误，敬请指正。

再解释一个参数shared_pool_reserved_size
这个参数设置的目的是为了保证大对象在内存中的装载。
对于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的值持续增大的

再解释一个参数
log_buffer这个参数
这个参数是设置log buffer的大小的一个参数，这个参数设置不当，对于redo data从内存清空到磁盘是有影响的，也是会影响系统的性能的

lgwr进程会在log buffer超过三分之一慢的时候，或者用户进程有commit或者rollback 操作的时候，或者dbwr进程要求lgwr进程写的时候，将log buffer里的内容写入磁盘。

如果log buffer设置的小的话，那么lgwr进程就会频繁的写磁盘，来清空log buffer。查看log buffer设置的时候合理，可以查看一个统计值，那就是redo buffer allocation retries，如果这个值持续增长的话，那就是说明log_buffer这个参数设置过小。

另外oracle说这个参数设置到1m之后，没有什么实际意义。但是就是设置大了，也没有任何的坏处，只是浪费一点内存而已，也不会丢失数据或者什么别的问题。
我感觉此参数在一般的生产系统设置为10m左右就可以了。我看到有的生产系统还会将这个参数设置为50m呢。

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

什么时候需要修改这个参数呢？需要满足以下的条件。
一个是由于大量的shared pool hitmis影响了用户的响应时间（就是当前的shared pool无法满足共享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只占很小的一部分。

我顶

今天刚好看到参数session_cached_cursors，顶一下

有同感

有同感。。。。

支持，不错的帖子...

恩，收了。不错！！