我们先来看这几个参数的意义
9:40:59 PM SQL> show parameter open_cursor
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
open_cursors integer 1000
每个session(会话)最多能同时打开多少个cursor(游标)
9:41:07 PM SQL> show parameter session_cached
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
session_cached_cursors integer 300
每个session(会话)最多可以缓存多少个关闭掉的cursor
9:41:27 PM SQL> select count(*) from v$open_cursor;
COUNT(*)
----------
63209
是指当前实例的某个时刻的打开的cursor数目
通过下面的sql我们可以看到open_cursor的参数是否合理
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 1000
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的值也不是越大越好,我们可以通过下面两条语句得出合理的设置
10:07:43 PM SQL> SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%cursor%';
NAME VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative 2091502820
opened cursors current 6051
pinned cursors current 1302
session cursor cache hits 1740081656
session cursor cache count 655382893
cursor authentications 457349
10:10:19 PM SQL> SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%parse%';
NAME VALUE
---------------------------------------------------------------- ----------
ADG parselock X get attempts 0
ADG parselock X get successes 0
parse time cpu 25036532
parse time elapsed 42808844
parse count (total) 1865045064
parse count (hard) 1320898
parse count (failures) 31568
parse count (describe) 8241
session cursor cache hits就是系统在高速缓存区中找到相应cursors的次数,parse count(total)就是总的解析次数,二者比值越高,性能越好。如果比例比较低,并且有较多剩余内存的话,可以考虑加大该参数。
使用下面的sql判断'session_cached_cursors' 的使用情况。如果使用率为100%则增大这个参数值
SQL> SELECT 'session_cached_cursors' PARAMETER,
LPAD(VALUE, 5) VALUE,
DECODE(VALUE, 0, ' n/a', TO_CHAR(100 * USED / VALUE, '990') || '%') USAGE
FROM (SELECT MAX(S.VALUE) USED
FROM V$STATNAME N, V$SESSTAT S
WHERE N.NAME = 'session cursor cache count'
AND S.STATISTIC# = N.STATISTIC#),
(SELECT VALUE FROM V$PARAMETER WHERE NAME = 'session_cached_cursors')
UNION ALL
SELECT 'open_cursors',
LPAD(VALUE, 5),
TO_CHAR(100 * USED / VALUE, '990') || '%'
FROM (SELECT MAX(SUM(S.VALUE)) USED
FROM V$STATNAME N, V$SESSTAT S
WHERE N.NAME IN
('opened cursors current', 'session cursor cache count')
AND S.STATISTIC# = N.STATISTIC#
GROUP BY S.SID),
(SELECT VALUE FROM V$PARAMETER WHERE NAME = 'open_cursors');
PARAMETER VALUE USAGE
---------------------- -------------------- -----
session_cached_cursors 300 40%
open_cursors 1000 12%
当我们执行一条sql语句的时候,我们将会在shared pool产生一个library cache object,cursor就是其中针对于sql语句的一种library cache object.另外我们会在pga有一个cursor的拷贝,同时在客户端会有一个statement handle,这些都被称为cursor,在v$open_cursor里面我们可以看到当前打开的cursor和pga内cached cursor.
session_cached_cursor
这个参数限制了在pga内session cursor cache list的长度,session cursor cache list是一条双向的lru链表,当一个session打算关闭一个cursor时,如果这个cursor的parse count超过3次,那么这个cursor将会被加到session cursor cache list的MRU端.当一个session打算parse一个sql时,它会先去pga内搜索session cursor cache list,如果找到那么会把这个cursor脱离list,然后当关闭的时候再把这个cursor加到MRU端.session_cached_cursor提供了快速软分析的功能,提供了比soft parse更高的性能
所以设置合理的session_cached_cursor可以降低我们的软解析
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/25462274/viewspace-2124992/
,如需转载,请注明出处,否则将追究法律责任。