You need to find a free buffer to cache the block, so you go to your LRU chain. But before you can scan your LRU chain, you must acquire the appropriate LRU chain latch. Your LRU chain is LRU 05 (in Figure 6-15), so you contend for latch CS 910. Finally, with both your LRU chain latch and the block in your PGA memory, you begin scanning LRU 05, looking for a free buffer. You first encounter buffer header BH 365 and examine the buffer header. The good news is the buffer is free, but the bad news is it's very popular, with a touch count of 12. So you promote the buffer to the MRU end of the list, and with great satisfaction, reduce its touch count to 0.

You move on to the next buffer header, BH 330. You examine the buffer header and discover it is a dirty buffer with a touch count of 1, which does not meet the default popularity threshold of 2. So, you move the buffer header to the LRU chain's write list. After you complete the move, you check the dirty list length to ensure it is less than _db_large_dirty_queue. The dirty list is only 6, which is less than the common default of 25, so you do not tell the database writer to write its write list.

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.