Yes, you are right about how threads are used to simulate asynchronous I/O for filesystem based datafiles. This is something that Solaris does, rather than Oracle. Please see my answer on Asynchronous I/O on Solaris for more on that.

Contrary to what Oracle have told you, asynchronous I/O is used for reads too, but only for direct reads. Direct reads are used for disk sort reads, parallel table scans and a few other operations. If you truss a shadow process doing a disk sort for example you'll see either pread64() or kaio(AIOREAD) lines corresponding to the temporary segment reads depending on what type of tempfile you have.

I have been observing a database built on filesystems (Oracle 8.0.6, Solaris 2.6, VxFS). The init.ora parameter disk_asynch_io is set to true. While looking at the number of threads on the DBW0 process by using the command ps -efL I find that DBW0 has 261 threads, whereas on a raw based database DBW0 has only 2 threads. Am I correct in guessing that Oracle is trying to simulate asynch I/O for the DBW0 process by spawning multiple threads, with each thread running the synchronous I/O command pwrite64(), or is the explanation something else.

On a similar note, while trussing the Oracle shadow processes on a raw device based database, I have never observed them trying to do asynch reads by using the system call aioread(), instead they seem to be doing the synchronous system call pread64(). However these shadow processes do have at least 4 threads. DBW0 on this raw based database does do asynch I/O as expected. Is there any reason for this behaviour? Oracle is saying that this is the normal behaviour, and that shadow processes do not use KAIO for reading, but try to simulaate asynch i/o by spawning multiple threads at the user level even on raw devices.