The solutions are very straightforward and centered around increasing the likelihood of blocks residing in the buffer cache. If the buffer were in the buffer cache, then this busy buffer wait situation would not exist. So think of ways to increase the likelihood of finding buffers in the buffer cache.

Application-focused solutions center on finding the top physical IO SQL and tuning it, focusing on reducing physical IO. Not only does this solution increase statement performance due to a decrease in block accesses, but it also reduces the chances of a buffer busy wait and allows blocks from other objects to be stored in the buffer cache. An Oracle-focused solution would be to increase the buffer cache to increase the likelihood of the buffer residing in the cache and therefore negating the need to make an IO call. An operating system-focused solution is to decrease IO read response times. The faster a block can be retrieved, the less time sessions will be waiting.

Personally, I seriously consider each option in parallel. I will detail this in the last chapter of this book, but I predict that the expected performance change in terms of throughput increase and response time decrease. I also include factors such as the difficulty and skill required, how long it will take to implement, and the uptime and availability issues. There are also other issues and things to consider that I may know nothing about. Perhaps there are considerations related to the business or budget. So I don't simply start with the SQL or with increasing the buffer cache. I gather information and help others gather information. Then, together, we cooperatively develop the best forward motion plan.