Now suppose you have scanned more than _db_writer_max_scan_pct buffer headers. If so, you would be very frustrated. You would have consumed a lot of CPU and held the LRU chain latch for a relatively long time. Suppose you have scanned more than this threshold. You now stop scanning, release the LRU chain latch, tell the database writer to free up some buffers, post the wait event free buffer waits, and patiently wait for 10 ms. The really interesting thing is that while you are screaming "free buffer wait!" for 10 ms, the database writer is busy writing dirty buffers to disk, making them free, and then inserting them back into the LRU end of the LRU chain.

Now that you've waited 10 ms, you wake up, acquire the LRU chain latch again, and start your search at the beginning-at the LRU end of your LRU chain. There is now a very high likelihood an unpopular free buffer is waiting there for you to replace. And there is! You pin the buffer header, release the LRU latch, update the buffer header, appropriately move the buffer header in the CBC structure so other processes can find the block you're bringing into the cache, replace the free buffer with the block you read from disk, and unpin the buffer header.

Notice what led the server process to post the free buffer wait event. First, it performed a physical IO read, which forced the server process to search for a free buffer. Second, it needed to scan too many dirty buffers, which means there must be active DML SQL. Third, the database writer had fallen behind in ensuring there were enough free buffers at the LRU end of the LRU chain. Each of the three conditions contributed to the situation, which means we have three solutions to the same problem!