ASM and stripe size mapping

The stripe size for ASM and RAID-10 data files are critical when the optimizer estimates the actual cost of a full-table scan.

In these days when most Oracle databases adopt either ASM or RAID-10 (stripe and mirror everywhere) approach, every table is physically mapped across many physical disk drives:

Estimating the cost of a full-table scan on a table with contiguous data blocks on a single disk is easy, it's the cost of moving the read-write head under the cylinder, plus the rotational delay as Oracle reads-in the data blocks.  However, in the real world ASM and RAID make the calculation of the cost of a full-table scan more challenging.   

It's the stripe size that matters most, because the stripe size dictates the number of contiguous blocks on each disks, which factors directly into the cost of the db file scattered read that are required to service the full-table scan.

Oracle Certified Master Steve Karam shares these this relationship between ASM, stripe size and LUN mapping:

See:  Mapping LUN and MAS to ASM

The x$kffxp fixed table contains the mapping between files, extents and allocation units and you can use this fixed table to track the stripe allocations across all of the disks for your table (assuming that you have allocated the large table into a separate data file, a Oracle best practice for large tables that span many disk spindles:

 But the stripe size is only one factor in weighting the relative costs of a full-table scan vs. index access.  We must also consider the number of rows returned by the query.  For example, if the query returns over half of the table rows, the full-table scan is almost always the fastest execution plan.  

If you like Oracle tuning, you may enjoy my new book "Oracle Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning tips & scripts.  You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.