* Increase CBC buckets. This rarely brings any performance relief because Oracle, by default, creates a tremendous number of buckets. Unless someone previously decreased the number of CBC buckets, increasing this parameter will probably have little effect on performance.

The LRU chains (or LRU lists, as they are sometimes called) have had their associated algorithms change many times over the years. But while the algorithms have changed, the functions of the LRU chains remain the same: to help keep popular buffers in the cache and to help server processes quickly find replaceable buffers. Anytime a single list strives to fulfill two missions, there will undoubtedly be some compromise. The LRU chains are no different. But as you'll discover, Oracle's current LRU algorithm implementation works wonderfully, supporting buffer caches over 100GB with the incredibly high transaction rates required for massive telecom and governmental systems.

Back in Oracle 6 days, there was only a single LRU chain protected by a single LRU chain latch. On large OLTP systems, DBAs battled LRU chain latch contention. But starting with Oracle 7, Oracle helped relieve the situation by segmenting the single LRU chain into many smaller LRU chains, giving each its own LRU chain latch. Every cached buffer is represented in the CBC structure and is also represented on either one of the LRU chains or one of the write lists (commonly called a dirty list). Buffers do not reside on both a write list and an LRU list.