Index full scan scans leaf blocks in key order. The test below is done in 9.2.0.5. create table test (x number not null, y number default 1); create unique index test_unq on test (x); explain plan select x from test order by x; -- make sure it's doing index full scan; add /*+ first_rows */ as needed alter session set events '10202 trace name context forever'; -- consistent read block header select x from test order by x; -- add /*+ first_rows */ to boost the chance of index full scan C:\oracle\admin\orcl9i\udump>grep "^Block header dump" orcl9i_ora_2756.trc | sort | uniq ... select dbms_utility.data_block_address_file(to_number('01c01af4','xxxxxxxx')),dbms_utility.data_block_address_block(to_number('01c01af4','xxxxxxxx')) from dual; ... You see file# and block# as follows: 7 6900 7 6901 ... 7 7326 Dump the blocks. You'll see 7.6900 is the first leaf block. From dba_extents, 7.6897 is segment header block. So 6898 is root block. Surprisingly, 6899 is another leaf block, not a branch block. Treedump (alter session set events 'immediate trace name treedump level 30382' where 30382 is object_id for the index) shows 7262 is the mid-level branch block, located somewhere away from here. *** 2007-03-05 11:04:59.241 ----- begin tree dump branch: 0x1c01af2 29367026 (0: nrow: 2, level: 2) branch: 0x1c01c5e 29367390 (-1: nrow: 362, level: 1) <-- 293673... instead of 293670... as other blocks are leaf: 0x1c01af3 29367027 (-1: nrow: 1 rrow: 1) leaf: 0x1c01af4 29367028 (0: nrow: 0 rrow: 0)