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.

From an Oracle perspective, I start thinking of any instance parameter that may increase Oracle's IO writing efficiency. For example, I would investigate looking for a way to increase the database writer's batch write size. As I mentioned, there are version-specific ways to alter the database writer's batch size. Investigate the _db_block_write_batch and the _db_writer_max_writes parameters. Also considering increasing the instance parameter _db_writer_max_scan_pct (the default may be 40, for 40%) or _db_writer_max_scan_cnt, as they determine how many LRU buffer headers a server process will scan before it signals the database writer to start writing. Increasing these parameters provides more time for the write list to build up, and therefore results in more blocks written per database writer IO request. This increase in efficiency can allow more blocks to be written to disk per second. My tests have shown that by increasing db_writer_max_scan_pct from 5 to 95, database writer operating system write calls decreased by 9% and db file parallel write waits decreased by 3%, while transaction activity increased by 14% and block changes per second increased by 19%. That's amazing, because just by changing this instance parameter, IO activity decreased while workload performed increased. This is exactly the type of improvement you want to see when tuning Oracle!

Another Oracle-centric possibility is to encourage server processes to not signal the database writer to write, thereby letting the write queue build up. When a server process, in search of a free buffer, stumbles across an unpopular dirty buffer and moves it to its associated write list, it also checks to see if the write list is long enough to be written. If it is long enough, the server process will signal the database writer to write. So a valid option, to allow the write queue to build up resulting in a larger batch write, is to increase the _db_large_dirty_queue (the default is 25 on some systems) instance parameter. But be careful about creating too large of a write queue. When the dirty buffers are being written to disk, they are unavailable for change. Any process that needs to change one of the buffers being written to disk must wait. The associated wait event is write complete waits. It is unusual for write complete waits to be the top wait event, but if someone has been altering the write queue length, this could occur.