* db file single write: This should never be the top wait event. This can possibly occur at the end of a checkpoint when all the database file header blocks must be written. These are done one at a time by multiple single-block writes.

I look at IO issues in term of requirements and capacity. When there is an IO issue, the requirements have exceeded the capacity. The only exception is when a locking or blocking type of issue occurs, such as with a free buffer waits event (discussed in the next section). When you see a database file write issue, except for locking/blocking reasons, you know the IO requirements have exceeded the IO subsystem's capacity. With modern IO subsystems, I never assume the requirements are due to the database I'm working on, or even another Oracle database. With complex IO management comes the increased chance a different system's files are residing on the same physical disk as my database's files. So I'm very careful in my IO subsystem assumptions.

IO issues can become very emotional. Vendors can get involved, and people start protecting their turf. To help move toward a solution, I frame the issues and solutions using OraPub's 3-circle analysis method. From an application perspective, I find the SQL generating the dirty buffers. You will find one or more update, insert, and/or delete operations. They must be there, or these wait events would never have reached the top of the list.