Before you can come up with good library cache performance solutions, you need to have a solid grasp of the library cache's architecture. With that knowledge, and the background presented in the previous chapters, you'll be able to grasp why a solution makes sense and the possible impact it can have.

The library cache architecture is extremely complex. The combined requirements of concurrency, relationships between objects, and fast searching really stress the architecture. I'll start at a very conceptual level of this architecture, and then methodically step down into ever increasing detail. I'll stop when the details are not particularly helpful for performance firefighting.

A wonderful conceptual library cache model is the traditional library. Let's say you want to find Ray Bradbury's book, Dandelion Wine. Because the library is a massive storehouse of books (think all library cache objects), sequentially or randomly searching would be futile. So you go the card catalog area (think hashing structure) and walk directly to the card catalog containing books pertaining to authors whose last name start with the letters A through D (think hashed to a specific bucket). There is someone in front of you, so you must wait (think acquiring the related hash bucket's latch). Finally, you are in front of the appropriate card catalog (think acquired the latch), and begin sequentially searching for the book (think sequentially searching a hash chain). Finally, you find the card and see the book's address 813.54 (think library cache handle). You walk over to where the book should be, find it, and start reading (think accessing the cursor). If you can picture in your mind this story, you are well on your way to understanding Oracle's library cache.