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.

While Oracle has a number of caches, the three I will cover in this book are the buffer cache, the shared pool, and the redo log buffer. These three caches are where most of your performance firefighting situations will arise. Surely, other problem areas exist, but when problems quickly and unexpectedly arise, from an Oracle-centric perspective, they usually are related to one of these caches.

Oracle has a big problem: When its customers purchase more memory, they expect performance to improve. Yet bigger caches require more CPU cycles to manage, and Oracle's algorithms, which were developed with the expectation of more IO and less memory, become stressed in ways they were not originally intended to handle. The result can be bizarre and deep contention related to memory structure.