* Large data warehouses have massive indexes, and when those massive indexes undergo a large range scan, thousands and thousands of index leaf blocks must be read into the cache. The problem, until Oracle8i, was if the index leaf block was not in the buffer cache, Oracle made a single block IO request (think db file sequential read) to bring the block into the buffer cache. The kicker was that since this was not a multiblock IO request, the index buffers were inserted into the LRU chain at the MRU end of the chain, destroying a beautifully developed cache, now completely full of index leaf blocks!

* When the data blocks were then requested (based on the index leaf blocks), they were also requested one at a time from the IO subsystem (think db file sequential read). So once again, these data blocks were placed in the MRU end of the LRU chain. As Oracle systems increased in size, Oracle's buffer cache decreased in usefulness.

At this point, Oracle had big problems brewing. With all the new Oracle features being considered and yet to be considered, Oracle couldn't simply add another clause to handle yet another unfortunate LRU chain situation. It needed a very general, flexible, and high-performing LRU chain algorithm. The Oracle developers found that in the touch-count algorithm.