This simple strategy worked well for Oracle until tables grew in size beyond the bonus and dept tables. The LRU chain in Figure 6-16 is eight buffer headers long. Suppose an eight-block table was just full-table scanned, requiring every block to be read into Oracle cache and its buffer headers to be placed into the LRU chain. When this algorithm was used, there was only a single LRU chain, so the entire LRU chain would be replaced with the full-table scanned table. So hour after hour of refining the cache to contain the popular buffers have just been obliterated. Users would certainly notice a performance change, and the IO subsystem would also take a beating. As database size continued to increase, Oracle clearly had to make a change, resulting in the modified LRU algorithm.

Oracle's well-known modified LRU algorithm was released with Oracle 6. It was touted as a major accomplishment, and Oracle developers were indeed very proud of their advanced buffer cache algorithm. After all, it did solve the key standard LRU algorithm problem.

Figure 6-17 shows the key aspects of Oracle's modified LRU algorithm. The only difference from the standard LRU algorithm is the creation of a window of just a few buffers at the LRU end of the LRU chain. The size of this window was only a few buffers (for example, four) and could be altered by the hidden instance parameter _small_table_threshold. This ensured that, regardless of how large the table being full-table scanned was, it would not obliterate a nicely developed cache.