Here's the problem: Because the library cache is shared among all sessions, some type of serialization control mechanism must be in operation. Whether the mechanism is latches or mutexes, that means CPU consumption for both acquiring the control structure and also accessing the memory structure. If the access becomes intense, significant contention can arise, causing serious performance degradation. So it's logical to ask what may seem like a silly question: "Can we simply not use a control structure?"

Sure we can, if serialization is not an issue. What Oracle has done is to reduce the likelihood of requiring serialized library cache access by providing each session with its own private library cache-like structure containing just the session's popular cursors (actually just the pointers to the cursors, which are their handles). Because the cursor cache is private, serialization is guaranteed, and therefore, no control structure is required! This is an elegant solution indeed.

This private library cache-like structure is called a session cursor cache. By default, every session has a cursor cache containing pointers to its popular cursors. By default, Oracle Database 10g Release 2 caches 20 cursor pointers. In Oracle Database 11g Release 1, the default is 50 cursor pointers. Regardless of the defaults, the cache size can be modified at the system level (not the session level) by altering the session_cached_cursors instance parameter.