>>>with 20 DBWrs, you have more working sets and more latches protecting the structures. the no.of buffers that each DBWR has to "manage" is lesser when you have more working sets (or DBWRs). Database writers don't "manage buffers". They get posted to work, they grab an LRU latch, they walk it looking at age and state to build a write batch--which includes marking it as "in flight" so that interested sessions will find that the buffer is busy (I seem to recall marking busy requires grabbing the associated chain latch, but I haven't been in the source since 8i so they may have piggy-backed under the LRU latch--who knows...). Then they throw the writes out and start polling for completions. As the completions come it, free the buffer and post free buffer waiters. There are port-level diffs in how the post/wait works such as whether it is just a goofy flurry of singleton IPC semaphore operations or a more elegant vectored posting. It makes about no sense to have more database writers than CPUs if you have async I/O (POSIX, proprietary or ODM). As an aside, and as usual for the sake of history, the idea of multiple writers (processes that build their own write batches) was not considered until the dawn of NUMA systems in the mid-to-late 90s. See, having a single writer build batches and task slaves is absolute murder on a NUMA system. All dbwr latching activity had to take place in the L3 of the building block where dbwr happened to be running. It was, um, horrible. So, Tirthanker Lahiri listened to our findings and analysis of our bus traces and implemented multiple true database writers...how nice. There is more info about that in James Morle's book... -- //www.freelists.org/webpage/oracle-l