When forcing objects to be kept in the shared pool, keep in mind that we are, in effect, gaming Oracle's least recently used (LRU)-based shared pool memory management algorithm. We are saying that we know better than Oracle does. This could actually be the case, since most DBAs know their applications very well. But until you do, stuffing your shared pool full of packages like a Christmas stocking can actually increase the likelihood of "out of memory" errors, because little room is left for all the hundreds-if not thousands-of other shared pool objects. So, think carefully before using this procedure.

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.