Well, you can and will see some db file sequential reads in a normal full scan. they are normally the result of:
we need to read file 42
we need blocks 9 thru 16
block 42.15 is in the buffer cache
multiblock read 9..14
singleblock read 16
buffer get 15
but yes, as demonstrated here
</code>
http://asktom.oracle.com/pls/asktom/f?p=100:11:::::P11_QUESTION_ID:35336203098853 <code>
when we full scan and hit the head row piece, we ignore it -- knowing full well we'll pick up the tail later (or we might already have hit it!! the tail could be in front of the head)
I would concurr after reading the text that it should only talk of chained rows in the context of a full scan, migrated rows are not a "single block io" issue in the context of a full scan.
I re-ran the tests on the above referenced link. A one million row table with in this run, 984,840 migrated rows:
select * from t
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 66668 5.30 5.17 18002 84668 0 1000000
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 66670 5.30 5.17 18002 84668 0 1000000
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 276
Rows Row Source Operation
------- ---------------------------------------------------
1000000 TABLE ACCESS FULL OBJ#(40909) (cr=84668 r=18002 w=0 time=1926673 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 66668 0.00 0.08
db file sequential read 1 0.00 0.00
db file scattered read 2272 0.00 0.16
SQL*Net message from client 66668 15.56 31.43