Out of the box and for 99% of all Oracle implementations, Oracle's LRU touch-count algorithm, combined with the default instance parameter settings, enables high-performance LRU chain activity with negligible contention. When the touch-count algorithm does get stressed, it's a unique combination of IO and CPU activity.

The LRU chain latches are named cache buffers lru chain. The hash chain latches are named cache buffer chains. The names are very close and can lead to quite a bit of confusion. Just remember that the LRU chain latches have lru in their name, and you'll be fine. On pre-Oracle Database 10g systems, the wait event will simply be latch free, so as I presented in Chapter 3, to determine the specific latch, you will need to reference the p2 column in v$session_wait or use the v$latch impact calculation strategy. For Oracle Database 10g and later systems, the wait event will be latch: cache buffers lru chain.

Without physical blocks being read from disk, there will be no LRU chain latch contention, because there will be no need to find a free buffer or insert a buffer header into an LRU chain. Database writers looking for unpopular dirty buffers will not stress the LRU chain structure enough to cause LRU chain latch contention. However, anytime a server process reads a block from disk, it must find a free buffer, which requires LRU chain activity (the exception is a direct read). If the IO reads are taking over 10 ms, then we are likely to see scattered or sequential reads instead of LRU chain latch contention. But if the IO subsystem is returning buffers in less than 5 ms, the stress can shift toward the CPU subsystem, and this is when LRU chain activity will begin to be stressed.