It is true that the comments in this article have drifted a bit from the original content of the article, but it has been an interesting conversation. In case it is not obvious to the casual reader of this blog, I think that I should point out that you have made excellent points in your comments. It would be interesting to see any insight that Jonathan or someone else could provide regarding the frequency of “db file scattered read” waits during index range scan operations – in my experience those operations appear to be infrequently used in the older Oracle Database release versions, but seem to be more common in more recent releases.

Two things about the Jonathan’s blog post that you have mentioned
1) It is dated 15th December 2006. Lots of things might have changed since (but it may still be valid). Just trying to read things in context of the time (as Jonathan himself says)
2) In the 2nd comment, Jonathan himself claims that it is his assumption, which was not proved then
As I said earlier, it was more of a “conventional wisdom” to say that Table Access By index range scan would (typically) cause “DB File Sequential Reads” waits. There would
always be cases where “DB File Scattered Read” waits would be observed but my understanding is it would be safe to treat such cases as exceptions (handled internally by Oracle) rather than rules.
I think I have managed to significantly divert the discussion from the topic of your original blog post so apologies for that.

Narendra,
Shortly after I posted my comment I thought about adding a couple of clarifications – my comment above might appear to be a little too harsh, essentially stating: “It happens this way, end of discussion.” There is a lot that I still do not understand about Oracle Database, so it is not my intention to say “End of discussion.” With my test case that I linked to above, you may see different results when testing different Oracle Database release versions or Standard/Enterprise edition (I saw db file sequential read waits on 10.2.0.2 Standard Edition).

I agree with you that the documentation link that I provided does not distinguish between adjacent and non-adjacent blocks when describing the “db file parallel read” wait event. Just because I said that something is true (in part 1 of the article series linked to in my previous comment) does not necessarily mean that it is true. However, a search of the Internet finds some agreement with my suggestion (disclaimer: I might have learned of this fact from this article), take a look at the article and the comments attached: http://jonathanlewis.wordpress.com/2006/12/15/index-operations/

You remind me once again about the importance of making a complete (and correct) statement. Thanks for that.
I think I wanted to say that when a table is accessed using an index range scan, the conventional wisdom said table blocks will
be read one-block-at-a-time (and hence might result in “DB File Sequential Read” waits). I think from 9i onwards, CBO was enhanced
to perform multiple single-block reads for a table (resulting from indexed range scan) in parallel, instead of accessing single (table) blocks (adjacent or not)
in a serial manner. I think Tom (as always) explains it nicely here

I did not intend to say it never happens. My point was about whether it is deterministic enough to make a generic statement.
I know very little about how CBO works and things change with each oracle version. During the OTN forum discussion that I had mentioned above,
I was not able to reproduce the behaviour with a couple of oracle versions. I will certainly see if I can reproduce the results with your test case.
BTW, I might have missed it but the documentation link that you have provided does not appear to make any reference to blocks being adjacent or not.

The “db file parallel read” wait event will appear when multiple non-adjacent blocks are read during a prefetch operation

Although I’m not Narendra, I think by “adjacent index blocks” he means “the blocks which are logically adjacent in the index structure”. So, they are read in parallel by process – it simply picks up ROWIDs of index blocks from a branch block and issues one request to access them all (maybe not all, I don’t know in-depth details).

The “db file parallel read” wait event will appear when multiple non-adjacent blocks are read during a prefetch operation, see the documentation:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3022

I think in that article Timur simply stated that he could not reproduce the results on a particular version – I believe that I had the same problem with the test case when I tried to produce the results on Oracle Database 10.2.0.2 Standard Edition. However, that does not mean that a db file scattered read operation cannot be used to read index blocks. You can see an example of that happening roughly half way through this article, as partially shown below:
http://hoopercharles.wordpress.com/2010/11/21/different-performance-from-standard-edition-and-enterprise-edition-2/
Standard Edition (obj# 20275 is the table T1, obj# 20276 is the index):

PARSE #2:c=15600,e=17980,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=2892477391,tim=176265018485
EXEC #2:c=0,e=24,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2892477391,tim=176265018563
WAIT #2: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=0 tim=176265018598
WAIT #2: nam='db file scattered read' ela= 76 file#=8 block#=8320 blocks=8 obj#=20276 tim=176265018735
WAIT #2: nam='db file scattered read' ela= 19381 file#=8 block#=8648 blocks=8 obj#=20276 tim=176265038168
WAIT #2: nam='db file scattered read' ela= 102 file#=8 block#=8344 blocks=8 obj#=20276 tim=176265038360
WAIT #2: nam='db file scattered read' ela= 98 file#=7 block#=3200 blocks=8 obj#=20275 tim=176265038517

I suggest reviewing the raw trace file to see why db file scattered reads were used during the execution. I suspect that you will find that many of those reads were used to fetch the table blocks (as indicated by the statistics) but could also be used to quickly read adjacent index blocks. See the comments and test case by Timur Akhmadeev in this thread for a demonstration of db file scattered read waits appearing during an index range scan:
http://forums.oracle.com/forums/thread.jspa?threadID=941864&tstart=0

********************************************************************************

SELECT /*+  */
  *
FROM
  (SELECT
    C1,
    C2,
    MAX(C3) C3
  FROM
    T1
  GROUP BY
    C1,
    C2
  ORDER BY
    C1,
    C2)
WHERE
  C1 BETWEEN 10000 AND 100000

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch       91      0.31       0.78       1440       1354          0       90001
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       93      0.31       0.78       1440       1354          0       90001

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 82  

Rows     Row Source Operation
-------  ---------------------------------------------------
  90001  VIEW  (cr=1354 pr=1440 pw=1440 time=4321 us cost=2004 size=3510078 card=90002)
  90001   SORT GROUP BY (cr=1354 pr=1440 pw=1440 time=1546 us cost=2004 size=2250050 card=90002)
  90001    TABLE ACCESS BY INDEX ROWID T1 (cr=1354 pr=1440 pw=1440 time=14292 us cost=1353 size=2250050 card=90002)
  90001     INDEX RANGE SCAN SYS_C009411 (cr=172 pr=224 pw=224 time=1731 us cost=172 size=0 card=90002)(object id 69857)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                      92        0.00          0.00
  SQL*Net message from client                    92        8.11        474.46
  db file scattered read                        180        0.03          0.58
  SQL*Net more data to client                     1        0.00          0.00

The first one is why we are seeing “TABLE ACCESS BY INDEX ROWID” instead “TABLE FULE SCAN” ???
And second one is why we are seeing “db file scattered read” instead “db file sequential read”?
I’m appreciating to help me.
Ghassem