Expert Oracle Exadata - Parent Directory

CHAPTER 12 MONITORING EXADATA PERFORMANCEExecution Plan Rowsource DetailsNow that you have checked the key metrics of your statement execution— duration, database time,parallelism used and how much of the database time is spent running on CPU vs. waiting— it’s time todrill down into the details of the execution plan at the row-source level. These are shown in Figure 12-8.Figure 12-8. Execution plan rowsource activity monitoring in the SQL Monitoring detail pageLet’s focus on the right-hand columns of the execution plan output first. The CPU Activity column showsa breakdown of total CPU usage by the statement so far. The longest bar at the SORT ORDER BY line in theexecution plan shows that this rowsource consumed 43% of total CPU usage of that statement executionso far. Note that this is 43% of total CPU consumption, not of total duration or database time of thestatement execution. You should examine the Time and Wait Statistics section (shown earlier, in Figure12-4) to see how much of the total database time was consumed by CPU usage and how much by waits.The Wait Activity column shows a breakdown of which wait events this statement execution waitedfor. Again, the SORT ORDER BY rowsource has experienced the most waits, 72% of total wait time of thatstatement execution. Note that this bar consists of two different color bars. If you move your mousepointer over these bars, you’ll see the names of these wait events. In this case these waits were directpath read temp and direct path write temp events, which you see with multi-pass work area operationssuch as sorts and hash joins. This column also shows percentages of total wait time of this statementexecution, not the percentage of total runtime duration, nor total database time.The IO Bytes column shows how many I/O operations or bytes were read or written by a rowsource.You can right-click on the chart to toggle the display of bytes or I/O operations. In Figure 12-8 you seethat the SORT ORDER BY rowsource has done a total of 241GB worth of I/O. When you move your mouseover the different color bars, you’ll see the details about how much was written and how much was read(roughly 50/50, as the chart seems to show). The execution plan step LOAD AS SELECT above it has writtenabout 125GB of data to disk. Note that this 125GB of data is measured at the Oracle database level, butthe lower-level ASM layer will likely mirror (or triple-mirror, depending on your configuration) thesewrites, so actually twice as many bytes were written physically to disks. You can check the Cell PhysicalIO Interconnect Bytes session statistic to see how much data was really sent (and received) over theInfiniBand network; this metric is aware of the ASM mirror write overhead and any other low-level traffictoo.388