Right away, Oracle states the assumption has changed. The assumption is the data resides in memory. In contrast to the standard Oracle kernel, where a balance must be struck between disk IO and in-memory operations, the TimesTen database is specifically designed for in-memory operations. It even goes so far as to say that an in-memory Oracle database cannot match the TimesTen performance! Clearly, trade-offs have been made to break speed barriers in specific processing areas.

The Oracle relational database management system (RDBMS) is not optimized for only in-memory management. I remember the day a small team in my consulting group did some testing using the standard Oracle kernel, but with a lot of memory. So much memory, in fact, that the entire database was cached. While our performance tests did run faster, we were shocked that they did not obliterate the baseline tests. What we learned that day was that the standard Oracle kernel is not optimized for in-memory operations. This is because it must strike a balance between in-memory operations and on-disk operations. As Oracle caches become increasingly larger, finding that optimal balance is a technically daunting challenge.

Finding the optimal in-memory to IO operations balance becomes even more difficult without changing core algorithms. So, as you might expect, Oracle has changed its core algorithms to keep up with larger caches and increased CPU processing speeds. Change represents risk. Oracle does not want to change its code unless it absolutely must. Unless you have worked on a large software product on which the entire existence of the company is based, this can be difficult to appreciate. Even the slightest change can cause unexpected and cascading performance issues, not to mention functional problems. So Oracle must see clear advantages and be highly motivated to take the risk of changing its code. As you will learn in this chapter, Oracle has taken this risk and continues to take this risk.