Expert Oracle Exadata - Parent Directory

CHAPTER 12 MONITORING EXADATA PERFORMANCELet’s look at a few more columns of the Real Time SQL Monitoring page. The Timeline column yousee in Figure 12-9 is one of the most important columns for understanding where the SQL statementspends its time.Figure 12-9. Row-source activity timeline in the SQL Monitoring detail pageThe Timeline column in the figure shows a visual timeline of individual execution plan rowsources’activity. It is based on ASH samples; ASH collects SQL execution plan line-level details starting fromOracle 11gR1. Look into the brackets in the Timeline column header. This should show you the totalruntime duration of this SQL execution, 2226 seconds in this case (around 37 minutes). So the totalwidth of the timeline column means about 37 minutes of wall-clock runtime. Now it’s easy to visuallyinterpret the length and position of these bars in each rowsource in the execution plan. When you lookat the TABLE ACCESS (FULL) T4 rowsource at the bottom of the plan, you see that this table scan wasactive from the beginning of the execution and continued up to around two-thirds of the total Timeline(to around 1400 seconds) and then it completed. So it looks like this table scan was active during most ofthe execution time.Oracle execution plans are trees of rowsource functions with strict hierarchy enforced, so a childrowsource can pass its results only to its direct parent. In our case, the TABLE ACCESS FULL against T4fetched some rows and passed them back to its parent operation, PX BLOCK ITERATOR, which then sentthe rows back to the PX SEND RANGE operator, which knows how to send results to other slaves via the PXTable Queue buffers in the SGA. Another set of slaves received these rows using the PX RECEIVErowsource and passed these rows to their parent, the SORT ORDER BY rowsource, which performed thesorting of these rows. Then the SORT ORDER BY rowsource just repeated its loop and asked for more rowsfrom its child operator PX RECEIVE, which then read (consumed) the table queue buffers for more rowsput there by the first set of slaves (producers). We are not going deeper into SQL execution engineinternals here, but hopefully this example has illustrated the hierarchical nature of the SQL executionand how the data “flows” upward through the execution plan tree toward the root of the tree (CREATETABLE STATEMENT in this case).When you look at the timeline bars, you see that all the bars starting from PX RECEIVE and below itstarted roughly at the same time and ended roughly at the same time, too. We say roughly, because thisdata comes from ASH samples, sampled once per second only, so we don’t have microsecond accuracyhere. And we don’t need it anyway, as our query runs for much longer than a second. But anyway, thetimeline bars indicate that the table scanning part of the query, including these “data transportation”steps for that data (PX RECEIVE, PX SEND RANGE, and PX BLOCK ITERATOR) took around 66% of the totalquery response time. If we want to make our query faster, we should probably focus on that part. weshould either scan less data, filter more (in cells hopefully), access less partitions or just increase the389