SQL> show parameter open_cursors --每個session（會話）最多能同時打開多少個cursor（游標）  

NAME                                 TYPE        VALUE 

------------------------------------ ----------- ------------------------------  

open_cursors     integer 300

SQL> show parameter session_cached_cursor --每個session（會話）最多可以緩存多少個關閉掉的cursor  

 NAME                                 TYPE        VALUE 

------------------------------------ ----------- ------------------------------ 

 session_cached_cursors     integer 20

SQL> select count(*) from v$open_cursor; --是指當前實例的某個時刻的打開的cursor數目 

COUNT(*) 

----------  

108

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 

------------------------ ------------  

28     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)就是總的解析次數，二者比值越高，性能越好。如果比例比較低，并且有較多剩余內存的話，可以考慮加大該參數。

c、使用下面的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 20     100%

open_cursors      300     16% 

當我們執行一條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更高的性能.

更新2：

OPEN_CURSORS是一個十分有趣的參數，經常有DBA發現自己的系統中的OPEN CURSORS十分大。我們看一個例子：

SQL>select sid,value from v$sesstat a,v$statname b where a.statistic#=b.statistic# and name='opened cursors current' order by 2;

 SID       VALUE 

---------- ---------- 

5430     93 

3527     95 

4055     96 

4090     97 

2012     98 

1819     98 

5349     102 

1684     103 

1741     116 

4308     169 

1970     170 

1369     181 

4208     184 

887      214

5215     214 

3518     214 

868      214 

1770     215 

4050     215 

1809     231 

3010     235 

762      237 

731      471 

4013     1066 

2648     1152 

2255     1172 

2322     2620

我們看到這個系統的OPEN_CURSORS參數設置為3000，而會話中當期打開CURSOR最大的會話居然達到了2620。在一般人的眼里，CURSOR使用后就關閉了，OPENED CURSORS的數量應該不會太多，難道應用程序出現了CURSOR泄漏，有些應用使用了CURSOR沒有關閉？實際上我們對OPEN CURSOR的概念一直存在誤解。認為只有正在FETCH的CURSOR是OPEN狀態的，而一旦FETCH結束，CLOSE CURSOR后，CURSOR就處于關閉狀態了。因此一個會話中OPEN狀態的CURSOR數量應該很少。事實上不是這樣的，某些CURSOR在程序中是已經CLOSE了，但是oracle 為了提高CURSOR的性能，會對其進行緩沖，這些緩沖的CURSOR，在程序中的關閉只是一個軟關閉，事實上，在會話中并未關閉，而是放在一個CURSOR緩沖區中。

在Oracle  9.2.0.5之前，OPEN_CURSORS參數的作用是雙重的，一方面是限制一個會話打開的CURSORS的總量。另外一方面，OPEN_CURSORS參數也作為PL/SQL CURSOR的緩沖。在PL/SQL中，如果某個CURSOR關閉了，這個CURSOR不會馬上硬關閉，而是首先保存在CURSOR緩沖中。如果這個會話當前打開的CURSOR數量還沒有達到OPEN_CURSORS參數的值，那么就可以先保持OPEN狀態。如果當前打開的CURSOR數量已經達到了OPEN_CURSORS參數的限制，那么首先會關閉一個被緩沖的，實際當時并未打開的CURSOR。如果緩沖池中的所有CURSOR都是實際打開的，那么就會報ORA-1000，"maximum open cursors exceeded"。

Oracle  9.2.0.5以后，OPEN_CURSORS參數不再承擔PL/SQL緩沖的工作,PL/SQL中的SQL也可以使用SESSION_CACHED_CURSORS的會話緩沖了。這個參數就成為了一個純粹的限制。

雖然如此，OPEN_CURSORS參數仍然和CURSOR的緩沖機制密切相關，因為這個參數限制了當前某個會話打開CURSOR的最大值。設置一個較大的OPEN_CURSORS參數，可以避免出現ORA-1000，同時也可以讓會話緩沖更多的CURSOR，改善SQL解析的性能。不過這個參數設置的較大會占用較大的PGA空間，消耗一定的物理內存。因此這個參數也不是設置的越大越好，一般的OLTP系統中，1000－3000就足夠了。在共享服務器模式的系統中，這個參數的設置要略微保守一些，因為這個參數越大，占用的SGA空間也就越大。

另外要注意的是，從Oracle  9.0開始，這個參數就已經是動態的了，可以隨時動態調整。