* Intimate relationships: Shared pool objects are related and can be intimately connected with each other. For example, a single table column may be related to literally thousands of SQL statements and programmatic constructs (functions, procedures, and packages). If that one column is altered, that single change can ripple (cascade) throughout all its relationships. The result could be the invalidation of every associated object, which would force recompilation and rebuilding of cursors, and that could require massive latching, pinning, and locking of resources. As you can see, these interconnected and dynamic objects present a very difficult problem.

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