Expert Oracle Exadata - Parent Directory

CHAPTER 11 UNDERSTANDING EXADATA PERFORMANCE METRICSphysical read total bytes optimizedThis statistic shows how many bytes worth of physical disk drive I/O was avoided either by reading itfrom flash cache or thanks to storage index I/O elimination. When you also see the statistic cell physicalI/O bytes saved by storage index equally increase, this means that I/O was completely avoided thanks tostorage indexes. If the storage index savings are smaller than the total optimized bytes, then the rest ofthe I/O was optimized thanks to reading it from flash cache, instead of the good old spinning disks (butI/O to flash cards did still happen internally). Interestingly, this statistic is not propagated toV$SQL/V$SQLSTATS and V$SEGMENT_STATISTICS views (at least as of Oracle 11.2.0.2). Kevin Says: “I’ve never really agreed with this particular counter. While it is true that a read from ExadataSmart Flash cache is optimized, when compared to a read from a hard disk, it is in no way as optimized as an I/Othat didn’t happen. In my mind, the savings tracked by this statistic are just too dissimilar to be all that helpful.”table fetch continued rowThis statistic is not Exadata-specific but is relevant when troubleshooting unexpected single-block readsdone by the database, while a Smart Scan is used. This statistic counts how many times Oracle had tofetch a next row piece of a chained row (using a regular single block read).table scans (direct read)This statistic is not Exadata-specific; it is seen in any Oracle database that is doing full table scans ontable segments using direct path reads. During serial execution, this statistic is incremented in thebeginning of the table scan, but with parallel execution, it is incremented each time a slave startsscanning a new rowid range distributed to it. Direct path reads are a prerequisite for Smart Scans tohappen, so if you don’t get your query to use Smart Scans, check whether a direct path read is used forscanning the table.table scans (long tables)This is a similar statistic to the previous one, but it shows whether the table scanned was considered tobe large or not. Actually, Oracle considers this separately for each segment. So some partitions of a tablemay be considered small, some large. If the segment (up to the high water mark) is bigger than 10percent of the buffer cache, the table is considered large and direct path reads are considered even forserial scans. (But note that this decision logic takes other things into account, like how many blocks ofthat segment already happen do be in buffer cache.) The 10 percent of the buffer cache rule actuallycomes from the _small_table_threshold parameter. This parameter defaults to 2 percent of buffer cachesize (in blocks), but Oracle uses 5 × _small_table_threshold as its direct-path-scan decision threshold.373