Just as with standardizing on segment extent sizes, having standard memory chunk sizes increases the likelihood of quickly finding suitable memory. The quicker memory can be found, the fewer CPU cycles will be consumed, the less time the shared pool latch must be held, and the less likely a lot of wasted small chunks of memory will exist (increasing the likelihood of a 4031 error).

Oracle itself continues to add new performance features to the core kernel. Sometimes these take the form of new features like a new SQL optimization path. Other times, it means replacing an existing function or algorithm that many kernel developers and most DBAs will be unaware of. One such optimization is the introduction of Oracle's patented in-memory undo (IMU). Essentially, instead of maintaining undo in Oracle segments, the undo is managed, as much as possible, in memory using structures optimized for in-memory operations. But as you will learn, how Oracle does this is fascinating and foreshadows even greater things to come. But with any piece of code, there is always the possibility of a bottleneck, so I'll cover how to detect IMU performance issues and multiple ways to solve the problem (in addition to just turning it off).

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.