How to demonstrate what is happening? Setting event 10200 causes all logical IOs to be written to a trace file. See:
http://www.freelists.org/post/oracle-l/Logical-IO,3
http://www.juliandyke.com/Diagnostics/Events/EventReference.html#10200

Keep in mind that Jonathan is referring to a very specific case in the response that you quoted, a case where there is a table with a single row in a table with a single column that also has an index on that single column. In such a case, the index structure will contain a single block – the root block, so an index access to the one block would require reading the index root block, and then the table block pointed to by the index entry. I believe that Richard Foote’s blog contains several examples of how this would work for very small index structures.

So, how to set up a test case (note that I modified this to have a table with two columns)?

CREATE TABLE T1 (
  C1 NUMBER,
  C2 NUMBER,
  PRIMARY KEY (C1));
 
INSERT INTO T1 VALUES(1,1);
 
COMMIT;
 
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T1',CASCADE=>TRUE)

OK, we now have a table defined with two columns, with a primary key index, and a single row. Now the test case:

SELECT /*+ GATHER_PLAN_STATISTICS FULL(T1) */
  *
FROM
  T1;
 
SELECT
  *
FROM
  TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SELECT /*+ GATHER_PLAN_STATISTICS INDEX(T1) */
  *
FROM
  T1;
 
SELECT
  *
FROM
  TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
ALTER SESSION SET EVENTS '10200 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'Event10200Test1';
 
SELECT /*+ GATHER_PLAN_STATISTICS FULL(T1) */
  *
FROM
  T1;
 
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'Event10200Test2';
 
SELECT /*+ GATHER_PLAN_STATISTICS INDEX(T1) */
  *
FROM
  T1;
 
ALTER SESSION SET EVENTS '10200 TRACE NAME CONTEXT OFF';

The output from the above for Oracle 10.2.0.x with an ASSM AUTO ALLOCATEd tablespace follows:

SQL_ID  0yp492wfxqf3q, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS FULL(T1) */   * FROM   T1
 
Plan hash value: 3617692013
 
------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   1 |  TABLE ACCESS FULL| T1   |      1 |      1 |      1 |00:00:00.01 |       7 |
------------------------------------------------------------------------------------
 
SQL_ID  2v0wvvx7sjxj8, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS INDEX(T1) */   * FROM   T1
 
Plan hash value: 3727918903
 
------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------------------------
|   1 |  TABLE ACCESS BY INDEX ROWID| T1           |      1 |      1 |      1 |00:00:00.01 |       2 |
|   2 |   INDEX FULL SCAN           | SYS_C0020540 |      1 |      1 |      1 |00:00:00.01 |       1 |
------------------------------------------------------------------------------------------------------

As you can see from the above, the full table scan required 7 logical IOs, and the index access required 2 logical IOs (1 for the index root block, and a second for the parent operation’s table access). Let’s take a look in the trace files:
From event10200test1 (full table scan – slightly trimmed for space):

Consistent read started for block 4 : 0110ae0c
Consistent read finished for block 4 : 110ae0c
Consistent read finished for block 4 : 110ae0c
Consistent read started for block 4 : 0110ae0d
Consistent read finished for block 4 : 110ae0d
Consistent read finished for block 4 : 110ae0d
Consistent read started for block 4 : 0110ae0e
Consistent read finished for block 4 : 110ae0e
Consistent read finished for block 4 : 110ae0e
Consistent read started for block 4 : 0110ae0f
Consistent read finished for block 4 : 110ae0f
Consistent read finished for block 4 : 110ae0f
Consistent read started for block 4 : 0110ae10
Consistent read finished for block 4 : 110ae10
Consistent read finished for block 4 : 110ae10

From event10200test1 (index full scan – slightly trimmed for space):

Consistent read started for block 4 : 0110ae1c
Consistent read finished for block 4 : 110ae1c
Consistent read started for block 4 : 0110ae0e
Consistent read finished for block 4 : 110ae0e
Consistent read finished for block 4 : 110ae0e

So, what are those blocks? Well, you could execute something like this to look at the table’s blocks (note that this could be very slow):

SELECT /*+ ORDERED */
  DE.BLOCK_ID+C.COUNTER BLOCK_ID,
  TO_CHAR(DE.BLOCK_ID+C.COUNTER,'XXXXXXXX') HEX_BLOCK_ID,
  DE.BLOCKS,
  C.COUNTER+1 COUNTER
FROM
  (SELECT
    BLOCK_ID,
    BLOCKS
  FROM
    DBA_EXTENTS
  WHERE
    OWNER=USER
    AND SEGMENT_NAME IN ('T1')) DE,
  (SELECT
    ROWNUM-1 COUNTER
  FROM
    DUAL
  CONNECT BY
    LEVEL<=64) C
WHERE
  DE.BLOCKS>C.COUNTER
ORDER BY
  C.COUNTER;
 
  BLOCK_ID HEX_BLOCK     BLOCKS    COUNTER
---------- --------- ---------- ----------
   1093129    10AE09          8          1
   1093130    10AE0A          8          2
   1093131    10AE0B          8          3
   1093132    10AE0C          8          4
   1093133    10AE0D          8          5
   1093134    10AE0E          8          6
   1093135    10AE0F          8          7
   1093136    10AE10          8          8

So, during the full table scan, Oracle read blocks 4, 5, 6, 7, and 8 – for a total of 5 logical IO blocks reads. But, the DBMS_XPLAN output clearly showed that were 7 logical IO blocks read, so what about the other two logical IOs. I suppose that there is another event that needs to be set to see those logical IOs.

It’s very interesting one. Also, can you please elaborate if possible from Jonathan post saying

” through the index, you will hit the root block of the index one, and the table block once for a total of 2 LIOs. If you do a tablescan you will access the segment header block twice (9i onwards) and the table block once for a total of 3 LIO”

1. Table scan will access segment block twice . How can we arrive at this number any proof

2. So, does this means that ever block access has 3 LIO for table.

3. If i am understanding right then for Index range scan it will hit root + branch + blevel (total 3 LIO) for ever scan.(every value scan) any example