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!

With all this touch count incrementing, resetting to zero, and touch count inquiry, the definition of a popular buffer begins to get a little nebulous. Is a popular buffer one that remains in the cache for 8 hours with an average touch count of 2, or a buffer that remains in the cache for 5 minutes with an average touch count of 250? Well, Oracle has determined a popular buffer simply needs a touch count greater than or equal to 1 (by default) when asked.