session_cached_cursors要点

session_cached_cursors要点

以前的总结都太长了，不方便大家阅读，还是来点短小精悍的吧。 也可以进QQ群 127149411讨论。 一、节省CPU 被Cache的Cursor只需在PGA中搜索，不在共享池中搜索。不必申请Library Cache Latch、不必父游标句柄、父游标堆0、子游标句柄、子游标堆0、子游标堆6这样一路找下去，可以直接定位到子游标堆6. 二、没有Library Cache log/pin以及相关Latch 11GR2后，软软解析只有两次Mutex，一次增加Mutex计数，一次减计数。如果在这两次Mutex期间遇到竞争，等待事件是Cursor:pin S 。 软软解析、执行阶段，除这两次Mutex之外，不再有任何形式的锁、Latch、Mutex。其他所有共享池相关竞争、等待事件，都是硬解析、软解析导致。 换句话说，共享池遇到除Cursor:pin S之外的其他等待，除想办法减少解析、执行次数外，佳解决方案：使用软软解析。 三、Cache cursor占用的共享池内存多吗 被Cache的Cursor，其父游标句柄、堆0和子游标句柄内存不能被覆盖，这几块所占内存不会超过一条SQL总内存的20%。除这几块外，子游标堆0、堆6，这些空间所占内存可以根据LRU法则覆盖。 甚至在一个进程正在软软解析期间，被Cache的Cursor其子游标堆0、堆6内存也可以被覆盖，之后再用到时，Oracle会重建子游标堆0、堆6。 因此，被Cache的Cursor占用内存并不多。可以放心调大session_cached_cursors数。 四、解决共享池争用的佳手段之一 使用软软解析，增高软软解析的比例。 五、注意事项 注意观察打开的游标数、缓存的游标数（比如资料：opened cursors cumulative、opened cursors current、session cursor cache count）。由于缓存的Cursor，占用的、不可覆盖的内存并不是太多，因此通常设置较高的session_cached_cursors数，并不会造成4031共享池内存不足错误。但还是要注意一下游标数量、所占内存总量。避免游标过多造成4031。