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.

The touch count reset has significant ramifications. First, this means touch counts will not skyrocket into infinity. Figure 6-21 is an example of what you may find in your production system. It may be surprising, but due to the touch count reset during promotion, buffer headers typically have a touch count of 0, 1, or 2. The touch count reset also means the most popular buffer headers will not necessarily have the highest touch counts. If you notice a particular buffer has a low touch count, you may have caught a popular buffer just after it was promoted or crossed into the cold region. In fact, the highest touch count buffer headers will reside near the LRU end of the LRU chain!