RE: "direct path read" and "db file sequential read" used for full table scans in 11g

From: bill thater <shrekdba@xxxxxxxxx>
To: Gaja Krishna Vaidyanatha <gajav@xxxxxxxxx>, Oracle-L List <oracle-l@xxxxxxxxxxxxx>
Date: Fri, 31 Aug 2012 05:43:46 -0700
Mmmmmmmmmm......cake...sorry ,I'M back now;]

sent from my Windows Phone
Bill"shrek" thater Oracle DBA
Shrekdba@xxxxxxxxx
"Oh boother said Pooh 'lock phasers on the hefalump. Mr.Piglet meet me
in transporter room three"
From: Gaja Krishna Vaidyanatha
Sent: 8/31/2012 2:13 AM
To: Oracle-L List
Subject: Re: "direct path read" and "db file sequential read" used for
full table scans in 11g
Hi Allen,
Regardless of the new feature in 11g, I have observed "db file
sequential read" events on even simple full table scans like - select
/*+ FULL(t) */ count(*) from xxx t. This occurs when Oracle is unable
to read DBFMBRC worth of blocks from a given extent. This usually
happens towards the edge of the high-water-mark of the table, but in
theory can happen in any extent of the table.

 For example, assume a given table has 8 extents (where each full
extent is 16 blocks of real data) and also assume that the total
number of blocks below the high-water-mark is 124. In this scenario,
the trace file will show 7 calls of "db file scattered read" (direct
path read in your case) and this accounts for 112 blocks. This will be
followed by 12 calls of "db file sequential read" to account for the
remaining blocks below the high-water-mark. So bottom line, even in
full-table-scans or index fast-full scans, there could be occurrences
of "db file sequential read" for Oracle to perform single block reads.

On a related note on setting DBFMBRC, I hope you are aware that from
10gR2 and up, the recommendation is to have Oracle set DBFMBRC
automatically to X (where DB_BLOCK_SIZE * X = 1MB). This will assist
in fewer read system calls and thus better elapsed times for
full-scans, when  compared to a smaller DBFMBRC set manually. This
"automatic feature" (you basically comment out the parameter OR just
remove it from the init.ora or spfile), allows the instance to have
large I/O chunk-sizes and prevents overly influencing the Optimizer,
that full-scans are cheap. So in a way, we get to have the cake and
eat it too. Hope this helps.

Cheers,

Gaja

Gaja Krishna Vaidyanatha,
CEO & Founder, DBPerfMan LLC
http://www.dbperfman.com
http://www.dbcloudman.com

Phone - +1-650-743-6060
LinkedIn - http://www.linkedin.com/in/gajakrishnavaidyanatha

Co-author: Oracle Insights:Tales of the Oak Table -
http://www.apress.com/9781590593875
Primary Author: Oracle Performance Tuning 101 - http://www.amzn.com/0072131454
Enabling Cloud Deployment & Management for Oracle & Big Data


________________________________
 From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
Sent: Thursday, August 30, 2012 2:47 PM
Subject: RE: "direct path read" and "db file sequential read" used for
full table scans in 11g

Question #3 is open again
According to the docs the answer I thought I'd found would only
explain what I'm seeing if I had the parameter
parallel_degree_policy=AUTO, but I just checked and it is set to
MANUAL, so the parallel queries should still be using direct path
reads according to the doc:
http://docs.oracle.com/cd/E11882_01/server.112/e25513/initparams179.htm#REFRN10310

SQL> show parameter PARALLEL_DEGREE_POLICY

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------
parallel_degree_policy               string      MANUAL


From: Allen, Brandon

I found the answer to question #3 - apparently it's a new feature
called "In-Memory Parallel Execution" as documented at the links
below.  I'm still looking for answers on #1 and 2 though if anyone has
any ideas.


From: Allen, Brandon



1)      How can I force production to use the direct path reads?

2)      Why is it using "db file sequential read" for a full table
scan instead of "db file scattered read"?

3)      I also tried setting PARALLEL to 2 on the table in question
and it did force Oracle to use a parallel execution plan, but it still
used "db file sequential read" instead of "direct path read" - any
idea why this could be?


________________________________

Privileged/Confidential Information may be contained in this message
or attachments hereto. Please advise immediately if you or your
employer do not consent to Internet email for messages of this kind.
Opinions, conclusions and other information in this message that do
not relate to the official business of this company shall be
understood as neither given nor endorsed by it.

--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
RE: "direct path read" and "db file sequential read" used for full table scans in 11g

Other related posts:
