Think about this for a second: If you ran a massive software company, would you sleep good at night knowing the next morning thousands of your customers would start using a brand-new algorithm in your core product and your employees have little real-world experience with the potential problems it may cause or what the solutions may be? It's not something most people consider, but over and over Oracle management must face this dilemma. So, before Oracle, or any software company for that matter, allows a new algorithm into their core bread-and-butter multibillion-dollar-brand product, it had better know that it works. And not just work, but work wonderfully. While CEOs may desire their picture on the front page of the Wall Street Journal, that's an IT manager's nightmare.

Oracle has a history of silently slipping core algorithm changes into its database server code. For example, in Oracle 7, the Oracle developers started instrumenting their code, resulting in the wait interface; the modified buffer cache LRU algorithm dramatically and silently changed, using the touch-count algorithm in Oracle8i Release 8.1.5; mutexes began being used in Oracle Database 10g Release 2; and as I'll detail in the next chapter, Oracle begin using multiple redo allocation latches in Oracle 9i Release 2. All these changes were never formally announced, and some still have not been announced or documented. If you haven't heard much about these changes, then Oracle developers did a good job of testing their code before it was released.

IMU is one such introduction. It became standard issue starting with the initial Oracle Database 10g release. Oracle knows that for many customers, segment management and, in particular, creating read-consistent buffers, consumes significant computing resources: memory, CPU, and IO. So if the developers can reduce one or all of these consumables while improving performance, they are thrilled. IMU is wonderful, and it sets the stage for transforming other traditionally segment-based operations into in-memory alternatives.