Oracle's buffer cache is a fascinating topic. It has everything you need for a fantastically horrific yet exciting performance nightmare: high concurrency, latches, locks, queues, lists, nodes, in-memory objects, and more. Add in a few irate users, and you'll have stories to tell you grandkids. With so many algorithms and pieces of kernel code simultaneously in operation, contention opportunities abound. Fortunately for us, an analysis focused on response time can detect specifically where the contention resides and, when combined with a solid understanding of the related internals, a number of possible solutions will result.

Oracle internals can become so interesting and addictive to people like us that within a few minutes, we will be talking about something that is truly fascinating but has relatively little practical value. Avoiding this has always been my challenge when teaching and writing. Here, I will attempt to balance my excitement with how things work with what is actually useful for firefighting. While there are many buffer cache topics, if it will not help you fight performance fires in a practical and realistic way, I will not write about it. If your curiosity is aroused, you can find many resources with further details about these internals.

For each topic, I will first present the general situation, followed by the related architectural aspects. Next, I will move on to how the structures can be stressed in such a way to cause performance degradation. Then I will present a number of solutions that directly address the problem. For each solution, I will explain why and how it can improve the situation and how the specific change will affect your system. This will allow you to better anticipate the effects of your change. In the final chapter of this book, I will present ways to quantify the expected solution change to help prioritize your recommendations.