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.

There are also times when we may want to pin small objects. For example, suppose an object has a pattern of intense activity, a long pause causing the object's memory to be deallocated, and then another period of intense activity. To ensure there is no application delay and to reduce memory management, we can simply pin the object. When we force objects to remain in the shared pool, keep in mind that in a very real sense, we are gaming Oracle's shared pool LRU algorithm. But sometimes this is what it takes.