Expert Oracle Exadata - Parent Directory

CHAPTER 11 UNDERSTANDING EXADATA PERFORMANCE METRICS Note: This chained row performance problem applies only to regular data blocks and those compressed withregular block-level compression (LOAD or OLTP). Luckily, it is not a problem for EHCC-compressed tables at all, asin EHCC the rows and columns are physically organized differently. Also, this issue does not apply to migratedrows (where the entire row has moved to another block due to an update, leaving only a stub head piece behind)when full-scanning through a segment. The full scan/Smart Scan just ignores the head pieces of migrated rows,as the entire row is physically elsewhere. Note that updates cause other efficiency issues for HCC-compressedtables, even if chained rows are not a problem.Another interesting case of row chaining peculiarities is when you have over 255 columns in a table.Even when the total row size is small enough to fit inside a single block, with over 255 columns, Oraclewould still do intra-block chaining, in which the row is chained but all the row pieces are physicallyinside the same block. This was needed because Oracle wanted to maintain backward compatibilitywhen they increased the column limit from 255 to 1000 in Oracle 8.0. The “column count” byte in a rowpiece is just one byte, allowing 255 columns per row piece, but thanks to chaining you can have morecolumns in next row piece(s). This, however, caused initially some performance problems for ExadataSmart Scans, where even intra-block row chaining resulted in a lot of single block reads. However thisbug (#9291589) was fixed in Oracle 11.2 Exadata Patch Bundle 4 (BP4) and you shouldn’t see it anymore.It was quite an interesting problem to troubleshoot; if you are interested in seeing more details,including the troubleshooting sequence, you can read Tanel’s “Troubleshooting Exadata Smart Scan”article about it:http://blog.tanelpoder.com/oracle/exadata/troubleshooting/chained rows rejected by cellThis statistic shows how many chained rows were not processed in the cell. We don’t know yet the exactreason for rejection as opposed to skipping (as in the next statistic, chained rows skipped by cell). Duringtesting, most of the chained rows will cause the next statistic to be incremented. So far we assume thatthis rejection is just a special case of not processing the chained row in the cell and falling back to blockI/O in database layer.chained rows skipped by cellThis is one of the main statistics to look at when troubleshooting “forced” single-block read issues inSmart Scans caused by row chaining. Following is a more extended output from the previous test case:371