Re: DWBR and dirty buffers

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:<cvmiji$c84$1_at_hercules.btinternet.com>...
> The exacts details could change with
> the size of the cache buffer - for reasons
> of side effects, not deliberate coding -
> a very small cache could results in a
> different pattern of delay block cleanout,
> a very large cache could result in a
> different availability of space for cloning
> blocks.
>
> Don't forget to allow time for the checkpoints
> to complete, otherwise blocks that are due to
> be written for the checkpoint still be reported
> as dirty.
>
>
> Could you clarify the line:
> > After second checkpoint all "xcur" are flushed except one, which is "cr".
>
> Blocks are not really 'flushed' by a checkpoint, only
> cleaned. So, in theory, you should see all the XCUR
> stay in memory and turn to CR
>
>
> You may find that a few blocks seem to stay as
> xcur - check the objd (data object id) for these,
> it will probably be about 4 billion - meaning it's
> from a rollback segment. There's always a little
> background activity going on which means that
> a few more blocks will be dirtied even as the
> checkpoint is running.
>
>
> --
> Regards
>
> Jonathan Lewis
>
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
> The Co-operative Oracle Users' FAQ
>
> http://www.jlcomp.demon.co.uk/seminar.html
> Public Appearances - schedule updated Jan 21st 2005
>

Thank you for clarifying of these points.

> Could you clarify the line:
> > After second checkpoint all "xcur" are flushed except one, which is "cr".
I repeate the same test like this one from my first post. When I force the second checkpoint I have checked the status of dirty blocks for this objects. The query return as result only one row (one block), which have status "cr".
All other are cleaned and query do not match them.

> Don't forget to allow time for the checkpoints
> to complete, otherwise blocks that are due to
> be written for the checkpoint still be reported
> as dirty.

Yes, I try but the result still the same even after 10 minutes on an idle database.
-- 1. create table, inserting 600 000 rows and COMMIT -- 2. force checkpoint
SQL> alter system checkpoint;
System altered
Executed in 2.266 seconds

• 3. checking dirty block by status SQL> SELECT status,COUNT(*) DIRTYBLKS FROM v$bh WHERE dirty='Y' and objd=39419 2 GROUP BY status; STATUS DIRTYBLKS ------ ---------- xcur 3400

Executed in 0.063 seconds

• after 10 minutes SQL> SELECT status,COUNT(*) DIRTYBLKS FROM v$bh WHERE dirty='Y' and objd=39419 2 GROUP BY status; STATUS DIRTYBLKS ------ ---------- xcur 3400

Executed in 0.078 seconds

> You may find that a few blocks seem to stay as
> xcur - check the objd (data object id) for these,
> it will probably be about 4 billion - meaning it's
> from a rollback segment.

Is this meant that these 3400 blocks are for rolback segments. They should keep pre-imaged data for this object and because that these blocks belongs to the same object. Received on Fri Feb 25 2005 - 05:59:56 CST