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.

--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l

Other related posts: