Referring back to our ITL entries, there are no more ITLs to consider, so we have completed our block clone. Any server process can now access CR buffer 7,678 consistent at time 12330.

It should now be obvious why ITLs are so important and that Oracle's read-consistent model, while extremely powerful and necessary and efficient, is still relatively expensive because it has the potential to consume a lot of CPU and IO, slowing application response time. Oracle is very aware of this, and in Oracle Database 10g Release 2, it started using in-memory optimized structures to temporarily store undo information. These objects are not segments and are therefore not subjected to segment-related overhead like CBC and LRU chain activity. In memory, undo is stored in the shared pool, which is covered in Chapter 7.

This brings us to the end of the buffer cache internals chapter. This is truly a fascinating topic, complete with interesting internal structures, latches, queues, high concurrency, in-memory objects, and ITLs! My hope is that I went deep enough into the internals to clearly explain the key Oracle buffer cache structures and their associated wait events, and then provide multiple practical solutions. I also hope I didn't go too deep and cross the border into interesting, yet not all that useful. Finally, I hope Oracle concurrency management is not such a mystery and, in your mind, fits together a whole lot better. Now it's time to turn our attention to Oracle's shared pool cache.