RE: excessive number of db writer

  • From: "Kevin Closson" <kevinc@xxxxxxxxxxxxx>
  • To: "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 6 Sep 2006 09:52:33 -0700

        >>>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
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
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
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 nice. There is more
about that in James Morle's book...

Other related posts: