My objective in this chapter is to clearly present the relevant architectural components of the shared pool, the performance challenges we face, and how we can alter the situation in our favor to improve performance. Many of the architectural concepts-such as hashing, hash chains, latches, and mutexes-have already been covered in earlier chapters, so let's dive right into the shared pool.

There are many problems-some would say challenges-associated with the shared pool. The constant inclusion of new memory structures, new requirements of all kinds, and highly dynamic memory management contribute to the situation.

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