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.
>=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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
