DBWn and LGWR are background processes. That means that they should do their work in the background, and in the ideal foreground or user processes should seldom have to wait for their services.

The obvious exception is that when foregrounds commit they must wait for LGWR to sync the redo for their commit. Asynchronous (non-blocking) I/O can reduce the average log file sync waiting time because LGWR can immediately enqueue the I/O requests even when there are other writes pending. Asynchronous I/O also allows the sync writes to multiple log file members to be enqueued and serviced in parallel.

In other respects the benefit of using asynchronous I/O for DBWn and LGWR is better scalability, not better performance. That is, it allows them to work more efficiently and thus manage higher workloads without foreground processes needing to wait significantly for their services. Thus in the absence of high workloads the impact of DBWn asynchronous I/O on performance is at best slight, whereas LGWR asynchronous I/O can have a significant impact.

As you have mentioned, if the DBWn workload is high enough to cause scalability problems, then multiple I/O slaves or DBWn processes can be used to compensate for the use of synchronous (blocking) I/O. There is in theory a similar facility for LGWR to use I/O slaves but I have found it to be almost entirely ineffective. Thus at high workloads asynchronous I/O is normally more important for LGWR than DBWn.

The is another important factor to consider when deciding whether to configure your database for raw asynchronous I/O. Namely that foreground processes will use asynchronous I/O to prefetch blocks that will soon be required for full table scans, fast full index scans, sort direct reads and other temporary segment reads.

In many databases the performance gain from asynchronous prefetching easily exceeds the benefit of faster log file syncs. The former is normally more important for data warehouse type applications, whereas the latter is normally more important for OLTP or web type applications. Thus whatever type of database you have, and whatever the load that it sustains, there is good reason for you to configure it to use true (raw) asynchronous I/O.

I recently discussed the effect of using async I/O with DB writer and LOG writer with someone, I was told that async I/O is more beneficial to DB writer than LOG writer. What is your opinion? Can the difference be quantified? I thought async I/O with DB writer can be compensated for by multiple DB writers, is there any comparison between the two?