Expert Oracle Exadata - Parent Directory

CHAPTER 12 MONITORING EXADATA PERFORMANCEscanning throughput (by increasing parallelism in this case, because this TABLE ACCESS rowsource wasn’twaiting too much for I/O, as shown in Figure 12-8, it’s not I/O-bound yet and the database nodes hadplenty of CPU resource left).When you look at the upper rowsources (LOAD AS SELECT and higher), you see that they have onlybeen reported active in the last third of the query response time, extending all the way to the end ofexecution. So, if we somehow made only this data loading part faster, we would only win up to 33% ofthe response time back, even if we could make the loading part infinitely fast. The table access andsorting would still take the majority of the response time. The timeline bars are very valuable for quicklyunderstanding in which execution plan tree part (branch) most of the response time is spent.The timeline bars are just the first thing to check. There are lots of other useful details in the SQLMonitoring report, too. For example, if you look at the SORT ORDER BY line in Figure 12-9, you see that thesort operation has been active throughout the whole execution of this statement. And if you know thebasics of sorting, it should make sense—the sorting rowsource was active for the first two-thirds of thetime because it was fetching data into sort buffers and sorting it (and spilling some data to temporarytablespace). After the sort itself was complete (the child rowsource returned an “end of data” condition),the sorting rowsource function had still had to be invoked. It is by invoking that function that the sortoperation returns the sorted rows to its parent operation. This is why the parent rowsources becameactive only toward the end of the execution timeline—because all the rows had to be fetched and sortedfirst, before anything could have been returned for further processing. And once all the rows werefetched and sorted, there was no reason for the SORT ORDER BY rowsource to visit its child rowsourcesagain. This is why the timeline bar for TABLE ACCESS ended at around two-thirds of the total executionduration timeline.Manually Querying Real-Time SQL Monitoring DataAll the pretty charts in Grid Control are based on some V$ or DBA_ views internally, so if you don’t happento have access to Grid Control or Enterprise Manager Database Console (or it is just broken), you can getwhat you want from the V$ views directly. You probably don’t have to access the V$ views for youreveryday monitoring and tuning tasks, but nevertheless it’s useful to know where this informationcomes from, as it may become handy for custom monitoring and advanced problem troubleshooting.Following are some key views to be aware of:• The GV$SQL_MONITOR view contains the statement execution-level monitoring data.When multiple sessions are running the same statement, you will have multipleentries in this view. So, make sure that you query the right execution, by using theright search filters. For example, you should pay attention to which SID andINST_ID you are really looking for (or PX_QCSID, PX_QCINST_ID if monitoring aparallel query) and whether the STATUS column still shows EXECUTING if you aretrying to troubleshoot a currently running query.• The GV$SQL_PLAN_MONITOR view contains execution plan line-level metrics,monitored and updated in real time. For example you can query theIO_INTERCONNECT_BYTES and compare it to PHYSICAL_READ_BYTES andPHYSICAL_WRITE_BYTES to determine the offloading efficiency by each individualexecution plan line, instead of the whole query efficiency. Note that increasing theoffloading efficiency percentage should not be your primary goal of monitoringand tuning – where you spend your response time, matters.390