重庆思庄Oracle、Redhat认证学习论坛

 找回密码
 注册

QQ登录

只需一步,快速开始

搜索
查看: 5407|回复: 0
打印 上一主题 下一主题

[Oracle] open_cursor和session_cached_cursor解释

[复制链接]
跳转到指定楼层
楼主
发表于 2017-6-30 16:35:31 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
open_cursors:
每个session(会话)最多能同时打开多少个cursor(游标)。
session_cached_cursor:
每个session(会话)最多可以缓存多少个关闭掉的cursor。
如何正确合理设置参数的大小?
a、如果Open_cursors设置太小,对系统性能不会有明显改善,还可能触发ORA-O1000:m~imum open CUrsOrs exceeded.的错误。如果设置太大,则无端消耗系统内存。我们可以通过如下的sql语句查看你的设置是否合理:

SELECT MAX(A.VALUE) AS HIGHEST_OPEN_CUR, P.VALUE AS MAX_OPEN_CUR  
   FROM V$SESSTAT A, V$STATNAME B, V$PARAMETER P  
  WHERE A.STATISTIC# = B.STATISTIC#  
    AND B.NAME = 'opened cursors current'  
    AND P.NAME = 'open_cursors'  
  GROUP BY P.VALUE;
HIGHEST_OPEN_CUR MAX_OPEN_CUR  
---------------- --------------------  
             18 300

HIGHEST_ OPEN CUR是实际打开的cursors 的最大值,MAX_OPEN_ CUR是参数Open_cursors的设定值,如果二者太接近,甚至触发eRA一01000错误,那么你就应该调大参数Open_cursors的设定值。如果问题依旧没有解决,盲目增大Open_cursors也是不对的,这个时候你得检查应用程序的代码是否合理,比如说应用程序是否打开了游标,却没有在它完成工作后没有及时关闭。以下语句可以帮助你确定导致游标漏出的会话:
SELECT A.VALUE, S.USERNAME, S.SID, S.SERIAL#  
  FROM V$SESSTAT A, V$STATNAME B, V$SESSION S  
WHERE A.STATISTIC# = B.STATISTIC#  
   AND S.SID = A.SID  
   AND B.NAME = 'opened cursors curent';  

同样,session_cached_cursors的值也不是越大越好,我们可以通过下面两条语句得出合理的设置。
SQL> SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%cursor%';  

NAME                                                                  VALUE  
---------------------------------------------------------------- ----------  
opened cursors cumulative                                             15095  
opened cursors current                                                   34  
session cursor cache hits                                             12308  
session cursor cache count                                              775  
cursor authentications                                                  324  

SQL> SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%parse%';  

NAME                                                                  VALUE  
---------------------------------------------------------------- ----------  
parse time cpu                                                          332  
parse time elapsed                                                     1190  
parse count (total)                                                    9184  
parse count (hard)                                                     1031  
parse count (failures)                                                    3  

session cursor cache hits就是系统在高速缓存区中找到相应cursors的次数,parse count(total)就是总的解析次数,二者比值越高,性能越好。如果比例比较低,并且有较多剩余内存的话,可以考虑加大该参数。


使用下面的sql判断'session_cached_cursors' 的使用情况。如果使用率为100%则增大这个参数值。
SQL>  SELECT 'session_cached_cursors' PARAMETER,  
  2           LPAD(VALUE, 5) VALUE,  
  3           DECODE(VALUE, 0, ' n/a', TO_CHAR(100 * USED / VALUE, '990') || '%') USAGE  
  4      FROM (SELECT MAX(S.VALUE) USED  
  5              FROM V$STATNAME N, V$SESSTAT S  
  6             WHERE N.NAME = 'session cursor cache count'  
  7               AND S.STATISTIC# = N.STATISTIC#),  
  8           (SELECT VALUE FROM V$PARAMETER WHERE NAME = 'session_cached_cursors')  
  9    UNION ALL  
10    SELECT 'open_cursors',  
11           LPAD(VALUE, 5),  
12           TO_CHAR(100 * USED / VALUE, '990') || '%'  
13      FROM (SELECT MAX(SUM(S.VALUE)) USED  
14              FROM V$STATNAME N, V$SESSTAT S  
15             WHERE N.NAME IN  
16                   ('opened cursors current', 'session cursor cache count')  
17               AND S.STATISTIC# = N.STATISTIC#  
18             GROUP BY S.SID),  
19           (SELECT VALUE FROM V$PARAMETER WHERE NAME = 'open_cursors');  

PARAMETER              VALUE      USAGE
---------------------- ---------- -----
session_cached_cursors    50        76%
open_cursors             300        15%




分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 支持支持 反对反对
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|手机版|小黑屋|重庆思庄Oracle、Redhat认证学习论坛 ( 渝ICP备12004239号-4 )

GMT+8, 2024-11-27 21:03 , Processed in 0.126365 second(s), 21 queries .

重庆思庄学习中心论坛-重庆思庄科技有限公司论坛

© 2001-2020

快速回复 返回顶部 返回列表