From:Steve Adams
Date:19-Apr-2001 02:17
Subject:   Buffer cache touch count LRU algorithm

Yes, the freeze CR behaviour was default in 8.1.5 only, although if I remember correctly the parameter appeared to be set to FALSE.

You seem to be right about _db_aging_cool_count. I had not tested that since 8.1.5 but having just re-tested it under 8.1.6 it appears that cooled buffers retain their touch count until they are heated again. Sorry for the misinformation. I have corrected the newsletter item on that point to include the words "(8.1.5 only)".

I thought CR accesses didn't accumulate touch counts. Or was that just 8.1.5? So setting this to true enables that functionality. How are buffers cooled? If I just keep touching blocks and they get moved to hot end, blocks pushed down below the 50% point don't appear to have their touch counts decremented.

OK, _db_aging_cool_count is what the touch count is reset to when a buffer is cooled, and _db_aging_freeze_cr is a boolean that can be used to prevent CR buffers from accumulating touches and being made hot.

Do you know the function of _db_aging_freeze_cr and _db_aging_cool_count? (Just idle curiosity). They seem to be for handling CR buffers.

Thanks for sharing this information. My experiments with these hidden parameters bear out what you say, except at one point. Namely, the default for _db_aging_stay_count seems to be 0, not 99. It reports as 0 in X$KSPPCV (et al), and although that is not conclusive it is easy to observe the touch count on buffers being set to 0 when moved, rather than to half their former touch count.

It appears that _db_aging_stay_count is primarily a touch count threshold above which buffers that would otherwise be cooled are instead moved back to the top of the hot region with half their touch count. The influence of this parameter on the touch count adjustment when buffers are moved from the cold region to the hot region is a secondary effect, intended to improve the fairness of its primary effect.

I did not go into detail in the newsletter about how all these hidden parameters work, because my intention there was just to explain the improvements in default behaviour rather than to teach people how to fine tune it. In fact, I recommend that you not attempt to tune any of the _db_aging parameters without getting someone like myself or Oracle development involved.

I just wanted to make a small correction to the touch count algorithm described in your October newsletter. The touch count is incremented only if _db_aging_touch_time seconds (default: 3) have passed since the touch count was last incremented. If it has been less time, it is not incremented.

If _db_aging_hot_criteria (default: 2) <= _db_aging_stay_count (default: 99) at instance startup, when the touch count is above _db_aging_hot_criteria it is eligible to be moved to the hot end of the list. The touch count is then halved when moved. So if it has reached 4 it will become 2 and is still eligible for promotion. This is the default behavior.

If _db_aging_hot_criteria > _db_aging_stay_count at instance startup, a block is eligible to be moved to the hot end of the list when the touch count exceeds _db_aging_stay_count. When it is moved, it is reset to _db_aging_stay_count.