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.

Finally, from an Oracle perspective, increasing the buffer cache can provide the database writer some relief from short but intense block change activity bursts. A larger buffer cache allows the cache to fill with dirty buffers, while not forcing the database to write unexpectedly, so it has more time to create larger and therefore more efficient batches. If you really want to stress a database writer, create a small buffer cache and get some DML going. You'll see the database writer frantically trying to rid the tiny buffer cache of dirty buffers.

From an operating perspective, there should be an IO bottleneck. While rare, if write caching is working wonderfully with IO write response times less than 5 ms, the total write time could be large enough to push, say db file parallel write, to the top. When this occurs, focusing on the IO subsystem will likely have little substantial effect. In this situation, focus on reducing the application IO write activity and increasing Oracle write efficiency. This also means creatively reducing write activity during peak database activity. Experienced DBAs have seen write-intensive IO activity like RMAN, backups and file transfers being performed during normal business hours. Decreasing non-Oracle IO requirements effectively increases the IO subsystem's capacity.