Re: Pluggable database in 12C

| "joel garry" <joel-garry_at_home.com> wrote in message
news:353e8f2b-2d9d-479b-8cfc-fd76c158cc84_at_jj5g2000pbc.googlegroups.com...
|
| I'm guessing the general idea is that more dbwr would be kicking at
| the lgwr to write things out more often, flushing private strands more
| often, letting them build up less stuff to flush. As the concepts
| guide puts it " If DBWn finds that some redo records have not been
| written, it signals LGWR to write the records to disk and waits for
| LGWR to complete before writing the data buffers to disk."

DBWn wakeup every 3 seconds to see if any modified buffers need to be copied to disc.
If you have more of them they share (pseudo-randomly, via the working data sets) the same
number of buffers and are (probably) all be signalled at the same time, so it's unlikely that
increasing the number will cause LWGR to get more signals.

I'm not certain of how the multiple DBWn interation with LGWR takes place, but if I am the
only DBWR I'll send one signal if I see two buffers that need to be written; if we are a pair of
DBWn who share that pair then one of us will send a signal for our one buffer, and the other
should detect that LGWR has already been signalled.

Regardless, I don't think this comes into play at the log file switch where the wait could be
seen as the "private redo thread" equivalent of the "LGWR wait for redo". (In passing, either
may be an indication of levels of concurrency or CPU utilisation that is causing delays between
a process being runnable and getting to the top of the runqueue).

Regards

Jonathan Lewis
http://jonathanlewis.wordpress.com/all_postings

Author: Oracle Core (Apress 2011)
http://www.apress.com/9781430239543 Received on Thu Oct 25 2012 - 11:00:51 CEST