* Latching: As you know by now, latching is all about serialization control. Because the shared pool contains memory structures, it relies on latches and mutexes for serialization. If it were about relational structures, there would be enqueues, which are focused on table and row locks. While shared pool-related latching has traditionally infused fear into most DBAs, the two core latches (library cache and shared pool) are used for very different purposes, and Oracle's wait interface clearly differentiates the two. This allows the performance specialist to know exactly what is occurring, resulting in a number of spot-on solution possibilities.

Fortunately for us, the wait interface will clearly tell us if the problem is latching, pinning, or locking. So while all of these may be involved, we will be able to prioritize their impact and develop appropriate solutions. During normal operations, pinning and locking are rarely a significant problem. When they are the problem, most DBAs will recognize their timing corresponds to some administrative tasks, such as altering objects, forcing recompilation, applying patching, or performing various upgrades.

I would say where most DBAs mess up shared pool latch contention is not clearly differentiating the latch situation, and therefore essentially making guesses at solutions. The library cache latch is related to finding objects in the shared pool. The shared pool latch is about memory management. Just keeping these two concepts clear will have a dramatic effect on your shared pool optimization success.