https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:865497961356
http://www.orafaq.com/node/758
https://docs.oracle.com/cd/E11882_01/appdev.112/e10646/oci09adv.htm#LNOCI091
https://docs.oracle.com/cd/E11882_01/appdev.112/e10646/oci09adv.htm#LNOCI16658
OPEN_CURSORS sets the maximum number of cursors each session can have open,per session.
SESSION_CACHED_CURSORS sets the number of cached closed cursors each session can have.
If SESSION_CACHED_CURSORS is not set,it defaults to 0 and no cursors will be cached for your session. (Your cursors will still be cached in the shared pool,but your session will have to find them there.) If it is set,then when a parse request is issued,Oracle checks the library cache to see whether more than 3 parse requests have been issued for that statement. If so,Oracle moves the session cursor associated with that statement into the session cursor cache. Subsequent parse requests for that statement by the same session are then filled from the session cursor cache,thus avoiding even a soft parse. (Technically,a parse can't be completely avoided; a "softer" soft parse is done that's faster and requires less cpu.) In the session cursor cache,Oracle manages the cached cursors using a LRU list.
I believe a lot of the confusion about open cursors vs. cached cursors comes from the names of the Oracle dynamic performance views used to monitor them.v$open_cursorshowscachedcursors,notcurrently open cursors,by session. To monitor open cursors,query v$sesstat where name='opened cursors current'. --total cursors open,by session select a.value,s.username,s.machine,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 current';