The session cursor cache is a doubly linked list of cursor instantiation
objects. When a session attempts to close a cursor, if the parse count on the
corresponding shared cursor is 3 or more, then subject to the
session_cached_cursors parameter the instantiation object on the LRU end of the
cache may be deallocated, and the instantiation object for the cursor being
closed is cleaned up and added to the MRU end of the session cursor cache LRU
list.

When a session attempts to parse an SQL statement, Oracle first scans the
session cursor cache (linearly) for the same statement, and if it is found it is
unlinked from the session cursor cache LRU list before use. When it is "closed"
it will be added to the MRU end of the session cursor cache again. Thus the
session cursor cache has a true LRU replacement policy.



-----Original Message-----
Sent: Wednesday, 30 August 2000 3:50


Has the session cache cursor a 'replace' policy or does it simply get full
and finish ? In the last case I interpret the results of 'session_cursor_cache'
as an indicator of the necessity to increase it (the side effect of no replace
policy could be the caching of the first different N but not necessarily the
most-used N cursors)