Re: Buffer Cache, Tuning

  • From: Mladen Gogala <gogala@xxxxxxxxxxxxx>
  • To: SinardyXing@xxxxxxxxxxxxx
  • Date: Mon, 01 Nov 2004 09:21:47 +0000

On 11/01/2004 03:02:55 AM, Sinardy Xing wrote:
> Hi all,
> Since DBW will flush buffer cache,

It doesn't do anything even remotely like "flushing buffer cache"
It writes modified blocks to disk, trying to keep up.

> every 3 seconds,

DBWR wakes up every 3 seconds and sees is there is anything to do.
This is not quite the same as flushing the buffer cache.

> every commit,

Unless commits are piggybacked. The main process which writes during
every commit is LGWR, not DBWR. Buffer cache has to accumulate the =20
sufficient number of dirty blocks for DBWR to start writing. DBWR is =20
lazy, not eager. It writes only when it has to. Still, a bit different =20
from "flushing buffer cache".

> when buffer pool 1/3 full

Then it scans for dirty buffers, doesn't necessarily write anything.

> Why we Oracle still need to introduce the DB_BLOCK_MAX_DIRTY_TARGET?

When there are more then that modified buffers which do not have a =20
backup copy on the disk (the definition of a dirty effing block) DBWR =20
starts writing. DBWR is a peeping Tom. It usually just scans for the
dirty blocks, but writes only if there is sufficient number. The =20
parameter you listed is the "suficient number" in V9. In 10, it is =20
gone. Gaja, Steve or Jonathan would probably know the 10g parameter
that decides the "sufficient number".

> >From what I can imagine 3 seconds per flush is reasonably fast.

It depends on how critical is the nature call. Sometimes, even 3 =20
seconds look like eternity. Here, I'm using a more convenient =20
definition of the flush.
Mladen Gogala
Oracle DBA


Other related posts: