Disk Read Unit Oracle v$sql (or v$sqlarea) has a column DISK_READS, which according to the Reference is "the number of disk reads for this child cursor" (or sum of child cursor disk reads in v$sqlarea). tkprof output has a comment "disk = number of physical reads of buffers from disk". But are they really number of disk reads, or number of disk blocks read (block in db_block_size)? I'll prove it's the latter. Before we do the test, I need to state that except for fast full scans, scanning indexes is db file sequential read, which always reads 1 block at a time. So generally there's no difference between the two units if a disk scan is on indexes. Now let's look at tkprof output and system call tracing. My database is 9.0.1.3 running on Solaris 2.6. db_file_multiblock_read_count is 8. I create a table with 500,000 rows. No index. Set 10046 event at level 12 in order to look at wait events (actually level 8 is enough). Set autotrace on. Select count(*) from this table. The plan shows full scan on the table. v$sql.buffer_gets shows 764, disk_reads 760, which are equal to autotrace Statistics consistent gets and physical reads, respectively. grep ^WAIT on the trace file for the session shows 8 'db file sequential read's (and of course p3=1), 95 'db file scattered read's (p3=8). truss -t read,pread,readv,write,pwrite,writev -c -p also shows 95 calls of readv, consistent with scattered read wait events. 95 x 8 = 760, exactly the same as disk_reads. This proves that 760 is indeed the number of disk blocks that were read, and they were read in 95 operations of readv(2). [Note 1] Cary Millsap and Jeff Holt in "Optmizing Oracle Performance" (O'Reilly, 2003) explained p, cr, and cu in SQL trace output as number of blocks read (disk or memory), not number of times of reading (see p.80 and p.85), and r and w in the same fashion (p.84). But cr on p.84 is explained as number of reads, possibly by mistake? [Note 2] If you run the test again, make sure the table blocks are not in buffer cache, or you wouldn't see db file scan wait events since the blocks don't need to be fetched from the datafile. You can flush the cache by offline and online the tablespace, or beginning with 9i, alter session set events 'immediate trace name flush_cache', and 10g, alter system flush buffer_cache. Yong Huang -- My tkprof output -- OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 11 0.14 0.33 2 2 0 0 Execute 11 0.03 0.10 0 12 3 3 Fetch 11 0.76 1.11 760 790 0 17 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 33 0.93 1.55 762 804 3 20 Misses in library cache during parse: 10 Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 15 0.00 0.00 SQL*Net message from client 14 31.46 31.52 db file sequential read 3 0.00 0.00 db file scattered read 95 0.06 0.29 OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 35 0.05 0.05 0 0 0 0 Execute 37 0.07 0.37 1 1 5 3 Fetch 68 0.00 0.03 8 94 0 45 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 140 0.12 0.46 9 95 5 48 Misses in library cache during parse: 24 Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ db file sequential read 9 0.01 0.02 12 user SQL statements in session. 34 internal SQL statements in session. 46 SQL statements in session.