Expert Oracle Exadata - Parent Directory

CHAPTER 11 UNDERSTANDING EXADATA PERFORMANCE METRICSthe full power of Smart Scan is not utilized, as the cells just read data blocks and return the blocks backto the database layer. In other words, in passthrough mode, the cells do not open datablocks and extractonly the required columns of matching rows, but return all the physical blocks of the segment as theyare. Note that the storage indexes (dynamically created in cellsrv memory) can be used to eliminate I/Oin the passthrough mode too, but these indexes must be populated by a regular Smart Scan, which doesactually open and process the data blocks in the cell.You should not see any passthrough Smart Scans happening on the latest database and Exadata cellversions unless you have problems like cells running out of memory and the like. You can test whathappens in a test-environment by setting _kcfis_cell_passthru_enabled to TRUE and running a SmartScan. You will still see cell smart scan wait event for your Smart Scans, but they are slower because theyare returning all the blocks to the database for processing.cell physical IO bytes eligible for predicate offloadThis performance counter holds one of the most important statistics for understanding cell Smart Scan.When you are Smart Scanning through a segment, this statistic shows how many bytes of that segmentthe Smart Scan would go through. Essentially, all the bytes from the beginning of the segment all the wayto its high water mark will be reported (as the scanning progresses through the entire segment). Thecatch is that this is the theoretical maximum number of bytes to scan through, but sometimes the cellstorage index optimization kicks in, allowing the scan to skip reading some block ranges. Even if thestorage index allows you to avoid scanning 80 percent of a 10GB segment, reducing the actual I/Oamount to only 2GB, this statistic still shows the total size of the segment scanned, regardless of anyoptimizations. In other words, this statistic shows the total bytes that would have been scanned through,if any cell level optimizations didn’t kick in (and often this is the case). Note that this statistic simplycounts the physical size of the segment in the data blocks in data files (and not the “eventual” data sizeafter any decompression, filtering, or projection).If this number does not increase for your session’s V$SESSTAT (or Statspack/AWR data when lookingat the whole instance), then it’s another indicator that Smart Scans aren’t being used. Any block rangesscanned through (or even skipped thanks to storage index optimizations) by a Smart Scan sessionshould increment this statistic accordingly. Another thing to know is that when the Smart Scan falls backto passthrough full block shipping mode (described earlier), the cell physical IO bytes eligible forpredicate offload statistic still gets incremented, although there’s no predicate offloading and Smart Scanfiltering done in the cell in passthrough mode.cell physical IO bytes pushed back due to excessive CPU on cellThis statistic is related to the selective fallback to passthrough mode as explained in Kevin’saccompanying note. The bigger this number is (compared to the cell physical I/O bytes eligible forpredicate offload statistic), the more the cell had to send back compressed CUs for decompression andprocessing in the database layer. This happens when the cell’s CPU utilization reaches a threshold andthere is enough spare CPU capacity available in the database layer, allowing you to utilize the CPUs ofyour whole Exadata cluster better.Note that this performance counter appeared as part of the cell software version 11.2.2.3.0 anddatabase Bundle Patch 6. It was apparently added as a temporary one-off fix, as this statistic replaced thead-hoc “spare statistic 1” counter in the V$ views. In fact, in Oracle 11.2.0.3 (and Exadata Bundle Patch 7),this statistic is renamed to “cell physical IO bytes sent directly to DB node to balance CPU usage.”365