The parallel scan is presumably doing
direct reads, which do not cause block
cleanout. The blocks are not read into
the buffer, and therefore could not be
written out after cleanout.
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )
Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )
____England______January 21/23
____USA_(CA, TX)_August
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
Vsevolod Afanassiev wrote in message
<4f7d504c.0301122354.5a7df7c1_at_posting.google.com>...
>
>3. The same query runs fine if a smaller partition is chosen (with
less
>than 500,000 blocks) or if PARALLEL hint (/*+ fuis used. As far as I
can see
>from V$SESSION_LONGOPS, parallel query splits the 1,000,000 blocks
>partition into chunks of approx. 125,000 blocks. I thought that
>if "delayed block cleanout" is a problem, then Oracle will need to do
it
>during parallel scan. However, a scan without parallel hint
>experienced "free buffer waits" problem when run AFTER parallel scan
>(on the same partition).
>
Received on Thu Jan 16 2003 - 09:27:15 CST
