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.

Oracle TimesTen In-Memory Database delivers real-time performance by changing the assumptions around where data resides at runtime. By managing data in memory, and optimizing data structures and access algorithms accordingly, database operations execute with maximum efficiency, achieving dramatic gains in responsiveness and throughput, even compared to a fully cached disk-based RDBMS.1