参数session_cached_cursors解释
------------------------------------------------
自己一直感觉对 的内存这一块儿理解不够深刻。
今天看到关于session_cached_cursors参数的解释。翻译一下。同时也加入一点自己的理解
oracle有一个 概念，那就是session cursor cache,中文描述就是有一块内存区域，用来存储关闭了的cursor。 当一个cursor关闭之后， oracle会检查这个cursor的request次数是否超过3次，如果超过了三次，就会放入session cursor cache，这样在下次parse的时候，就可以从session cursor cache中找到这个statement-> Alan：其实这里就是把cursor缓存在了PGA里面(privatearea)。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只占很小的一部分。
------------------------------------------------
自己一直感觉对 的内存这一块儿理解不够深刻。
今天看到关于session_cached_cursors参数的解释。翻译一下。同时也加入一点自己的理解
oracle有一个 概念，那就是session cursor cache,中文描述就是有一块内存区域，用来存储关闭了的cursor。 当一个cursor关闭之后， oracle会检查这个cursor的request次数是否超过3次，如果超过了三次，就会放入session cursor cache，这样在下次parse的时候，就可以从session cursor cache中找到这个statement-> Alan：其实这里就是把cursor缓存在了PGA里面(privatearea)。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/22021749/viewspace-611646/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/22021749/viewspace-611646/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
