RE: excessive number of db writer

>>>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...

--
http://www.freelists.org/webpage/oracle-l