* Application-focused: From an application perspective, there absolutely must be SQL asking for blocks that do not reside in Oracle's buffer cache. If the blocks were in the cache, the server process would not have issued a multiblock read request resulting in the db file scattered read wait event. To find the responsible SQL, look for the SQL with the most block reads (sometimes called block gets or what I call physical IO). The SQL must be there, and you will see it. To reduce the physical IO pressure the application is placing on Oracle, which then impacts the operating system, tune the SQL or reduce its execution rate.

This situation is very common; if you have not encountered it before, you will. The key to diagnosing this situation (or any for that matter) is to not remove initially uncomfortable data from your analysis. Either the data is incorrect (which is something to consider) or your analysis is not yet complete.

Up to this point, all wait time discussed has been the average wait time. Just as with weather temperatures, you should expect values both above and below the average. While the average conveniently simplifies potentially thousands of values into a single value, we do lose some information through this statistical simplification. Starting with Oracle Database 10g, the view v$event_histogram provides a more detailed look into the actual wait times, providing more than just the simple statistic of average.