When memory is in short supply, Oracle will deallocate unpopular chunks of memory. You probably have experienced this when attempting to retrieve a SQL statement's text and it is no longer cached in the shared pool. Fortunately, Oracle will not deallocate memory that is in use. For example, if a cursor is pinned, Oracle will not deallocate the associated memory, regardless of how unpopular it may be. In fact, even flushing the shared pool will not remove pinned cursors! If you really want to empty the shared pool and start from the beginning, you must recycle the instance.

The shared pool latches are used to serialize shared pool memory management. This means operations such as searching for memory, LRU activity, allocating memory, and deallocating memory require a shared pool latch. Because multiple subpools exist starting in Oracle9i, and each subpool has it own shared pool latch, simply running this version or later greatly reduces the likelihood of shared pool latch contention. But sometimes that is still not enough. The following are some possible solutions that will decrease latch acquisition time, latch hold time, or both.

This strategy is used to ensure objects successfully make it into the cache, regardless of the memory activity or the object size. The first time any package is called, the entire package is loaded into memory. If this need arises after an active shared pool has been in operation, it can force substantial memory management activity, which could result in the object not being able to load, resulting in a 4031 error. Even if the object does successfully load, the user may notice the application delay.