Re: Buffer Cache, Tuning

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.

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

>=20
> 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".

>=20
> when buffer pool 1/3 full

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

>=20
> 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".

>=20
> >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.
--=20
Mladen Gogala
Oracle DBA

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