Note in-line.
--
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
Optimising Oracle Seminar - schedule updated July 14th
"Mladen Gogala" <gogala_at_sbcglobal.net> wrote in message
news:pan.2004.07.16.17.18.32.479640_at_sbcglobal.net...
> On Fri, 16 Jul 2004 08:00:05 -0700, utkanbir wrote:
>
> > Hi ,
> >
> > i read in manual that parallel reads dont use buffer cache instead use
> > pga memory . So when i issue a select statement in parallel , i expect
> > to see the following things:
> >
> > 1. since the read is parallel , buffer cache is not used , the data is
> > not cached so there will be no entry in gv$bh for the table.
> > 2. gv$sessstat.name 'physical reads direct ' must be non zero .
> >
> > Are these correct?
>
> No.
>
> Parallel reads/writes are usually recovery related. Direct reads skip
> the buffer cache and go directly into the PGA. Thus the name. Scattered
> reads usually point to full scan (either table or index), while continuous
> reads/writes usually mean single block index I/O.
>
>
The OP seems to be talking about Parallel Query.
When a PX slave does a tablescan or index fast full scan,
it uses 'direct path reads', which do, indeed, go into local
memory, and bypass the buffer cache; and do get recorded
in v$sysstat et. al. as "physical reads direct".
It is still possible for such blocks to appear in x$bh though,
as other SQL may be querying or modifying the data.
It is possible for PX slaves to read data (such as partitioned
tables, or indexed accesses into secondary tables driven
by the parallel scan) into the buffer cache.
Received on Fri Jul 16 2004 - 15:29:11 CDT
