* Pinning and locking: Similar to the situation with Oracle buffer headers, the central shared pool object-the cursor-can be pinned and locked. Pinning ensures memory is not improperly deallocated and can also be used to ensure serialization. Locking is used to prevent an inappropriate change. They can be used together. For example, during a procedure compilation, the related cursor can be pinned to ensure the memory is not deallocated and locked to ensure no other process can inappropriately change the related objects. And, of course, latching can be involved to ensure serialization.

* 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.