Expert Oracle Exadata - Parent Directory

CHAPTER 11 UNDERSTANDING EXADATA PERFORMANCE METRICSpiece), cellsrv falls back to regular block I/O for that row and sends the block back to the database layerfor normal processing. The database layer can then extract the data block address of the next row piecefrom the row head piece and issue the block read I/O to the appropriate cell where the ASM striping hasphysically put that block. The reasoning and fundamental problem behind this optimization is similar towhy consistent read rollbacks have to be done in the database layer as opposed to a cell—it’s becausesome of the data blocks required for this operation may just happen to be located in another cell, andcells never talk to other cells.This behavior means that your Smart Scan performance will drop if it hits a lot of chained rows andhas to fetch their next row pieces. If you get lucky and access only the columns that are present in thehead piece of the row, then you won’t have to fall back to database block I/O mode for these blocks andyour Smart Scans will be fast. If you have to fetch the next row pieces, however, then your Smart Scanwill be constantly interrupted by the fall-back to block I/O, and the database layer starts doing logicalreads (and possibly single-block physical reads as well, if these blocks are not cached in buffer cache).This means that your query ends up waiting most of its time for random single-block reads as opposedto high performance Smart Scanning. Following is the response time profile from a test session hittingmany chained rows and spending 86 percent of the response time on cell single block physical readswaits. Thankfully, there is a statistic table fetch continued row (which is useful also on non-Exadatadatabases), which counts how many times we had to follow a “next” row piece of a chained row. In thefollowing case around 11320 row pieces had to be fetched using single block reads:--------------------------------------------------------------------------------------SID, USER , TYPE, STATISTIC, HDELTA--------------------------------------------------------------------------------------698, TANEL, STAT, table fetch continued row , 11.32k698, TANEL, TIME, DB time , 3.96s698, TANEL, WAIT, cell smart table scan , 5.82ms698, TANEL, WAIT, cell single block physical read , 3.93s---------------------------------------------------------------------------------Active% | SQL_ID | EVENT | WAIT_CLASS---------------------------------------------------------------------------------86% | axf3y5zg64vsu | cell single block physical read | User I/O14% | axf3y5zg64vsu | ON CPU | ON CPUNow, this chained rows processed by cell statistic indicates that a chained row was hit by Smart Scanand was processed within the cell (exactly the opposite of what we just said). This statistic getsincremented in a special case of intra-block chaining, in which the next row piece is stored in the sameblock as the current (head) row piece of a chained row. Intra-block chaining is used for storing rows withmore than 255 columns. In such cases the storage cell notices that it just has to fetch the rest of the rowfrom the same block, which it already has opened and can process this chained row without resorting todatabase block I/O.370