Oracle also allows a touch count to be missed. There is no latch involved (which is a fantastic way to eliminate latch contention), and Oracle does not pin the buffer header. Without serialization control, two server processes can increment and update a buffer header's touch count to the same value!

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.