* Find and tune physical IO SQL. Without a block read from disk, there would be little cause for a free buffer waits event. Find the top physical IO SQL. Usually there are only a few large SQL statements consuming physical IO that clearly stand out. Tune or reduce their execution rates with the objective of reducing the amount of physical IO generated.

* Find and reduce DML SQL impact. Since a free buffer waits event is related to too many dirty buffers in the LRU chain, there must be DML SQL. Depending on your performance tools, DML SQL can be difficult to find because it may be a high physical IO, logical IO, execution rate, or CPU consumer. It could be a sneaky combination of many statistics. If I cannot view the type of SQL (v$sql.c_type), then I look at both the top physical IO and logical IO SQL, and then check the statement itself. There is a good chance the DML SQL is also the top physical IO SQL statement as well (I see this a lot). If so, you've hit the jackpot and know you have found the key SQL statement. For more details about identifying DML SQL, refer to Chapter 8 section Application-Focused Solutions for Log File Parallel Write Contention. The objective is to reduce the impact, so that can mean tuning and also workload balancing, which will reduce the execution rate during peak times.

Buffers cannot be locked, because they are not relational structures. However, for a number of reasons, they can be temporarily unavailable. When this occurs, the buffer is deemed busy. Distilling all the complexity down to its essence, a buffer busy waits event is about limited concurrency. A process needs to access a buffer, but it can't because another process is accessing the buffer and won't allow concurrent access. There are a number of situations when this can occur and specific solutions in each case.