* Memory fragmentation: Oracle has made absolutely amazing progress in this area. Memory fragmentation used to be one of most common performance problems. But Oracle has taken a number of steps in both architecture and instance parameter flexibility, allowing us ways to influence Oracle to better adjust its behavior to a particular application's character. Throughout this chapter, notice how memory management has evolved, and how we can alter and influence Oracle's shared pool memory management.

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