As an example, suppose that server process S100 gets the buffer header's touch count at time T0, which is 13, and it begins the increment to 14. But server process S200 now asks the buffer its touch count at time T1, and since server process S100 has not completed the increment, it shows its touch count to still be 13. Server process S200 now begins the increment from 13 to 14. At time T2, server process S100 changes the buffer header's touch count to 14, and at time T3, server process S200 also changes the buffer header's touch count to 14. Is it significant that a touch count increment was missed? No structures have been corrupted, and the touch count has indeed been incremented, but just not twice. In the larger scheme, if the buffer is indeed popular, it will be touched again. What Oracle has saved with this fuzzy implementation is CPU consumption and the amount of kernel code being run.

You may have noticed that I've have not said that when a buffer gets touched, it is promoted to the MRU end of the LRU chain. This is because buffer header touching and buffer header promotion are now two separate actions. When a buffer is considered for promotion, it is also considered for replacement. While both server processes and database writers can promote buffer headers, only a server process will replace a buffer and its associated buffer header as a result of a physical block IO read. It doesn't make sense for a database writer to perform a replacement, since it has nothing to replace.

Figure 6-20 is a flowchart of what I'm about to explain. After a server process reads a data block from disk, it must find an unpopular free buffer to replace with the just-read data block. The server process acquires the appropriate LRU latch, and then starts scanning buffer headers at the LRU end of the LRU chain. Remember that the buffer headers reside on the LRU chains, not the buffers. If the server process bumps into a free buffer header, then it checks if it is popular. If it is popular, the server process promotes the buffer header and continues scanning. If the free buffer header is not popular, the server process replaces the buffer with the block read from disk, updates the buffer header, and moves the buffer header to the LRU chain midpoint. Notice there is no need to update the CBC structure, because the buffer has not moved; only the buffer header on the LRU chain has moved. If the server process bumps into a dirty buffer header, then it checks if it is a popular dirty buffer header. If the dirty buffer header is popular, it promotes the buffer header and continues scanning. If the dirty buffer header is not popular, the server process moves the buffer header to the write list. If the server process bumps into a pinned buffer header it, simply continues with its scan. Pinned buffers are off limits.