A buffer header's life in an LRU chain begins at the midpoint. Because other buffer headers are being replaced and inserted into the midpoint, as buffers get promoted, a buffer header naturally migrates toward the LRU end of the LRU chain. As presented in the previous section, the only way for a buffer header to get promoted is to be identified as popular. Another significant event occurs when a buffer crosses the midpoint, moving from the hot region into the cold region.

When a buffer crosses into the cold region, its touch count is reset to a default of 1 (_db_aging_cool_count). This has the affect of cooling a hot buffer, something no buffer who desires to remain in the cache wants to occur. Increasing this parameter will artificially increase buffer value, thereby increasing the likelihood of buffer movement.5 So, by default, when a buffer header crosses into the cold region, it must be touched at least once to match the promotion criteria (_db_aging_hot_criteria).

You may wonder why Oracle resets the touch counter when a buffer header is promoted and also when it crosses into the cold region. The key to understanding this lies in the midpoint. While the midpoint defaults to evenly split each LRU chain into hot and cold regions (_db_percent_hot_default=50), it can be set to anything at and between 0 and 100. If the LRU chain becomes a 100% hot region, then the only reset will occur when a buffer is promoted.6 When Oracle releases the ability to create any number of buffer pools (as DB2 has for many years), the ability to manipulate the midpoint in each pool will allow for highly optimized and specific LRU activity. So while the double reset may initially seem silly, it does serve a real purpose and sets the stage for the future.