10.07.2015 Views

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 12 MONITORING EXADATA PERFORMANCEFigure 12-2. Statement Duration compared to Database Time in the SQL Monitoring pageThe Duration column shows what users care about, which is the response time of a query since the SQLexecution start. This is the time they have had to wait for the SQL to complete. Of course, the end usersmay have had to wait for much longer than the duration of the query, as the page in Figure 12-2 showsonly the database response time. Time may have also been spent in the application layer or the networkconnection in between the user and the application server.It is important to know that the duration measures time from SQL execution start all the way untilthe cursor is closed or cancelled (for example, when all data is fetched from it). This means that if yourdatabase can process the query in 30 seconds, but then millions of rows are fetched a few at a time, yourquery will take a long time as far as the application is concerned (thanks to the network ping-pong), butin fact only a little time is spent processing within the database. The Duration column still shows longquery “runtime,” as the cursor is still kept open for fetching of the data. Remember, the durationmeasures time from when the cursor is executed all the way to when it is finally closed after all thefetches are done or the application has fetched enough.This leads us to the next important metric—Database Time, seen in the sixth column in Figure 12-2.The Database Time metric shows the total time your query spent executing in the database. So, if yourun a serial DML that runs for 60 seconds and spends all of the time executing inside the database, youwill end up seeing 60 seconds of database time, too. However, if you are running some SELECT statementand are fetching a lot of rows, causing your session to spend (let’s say) 50% of its time executing in thedatabase and another 50% waiting for the next fetch command (once it has sent an array of rows back tothe application), you would see only half of that total 60-second duration as database time. In otherwords, you would see 30 seconds of database time, as the database session has been servicing yourrequest only for 30 seconds and the rest of the time it was idle.Looking at the second entry in Figure 12-2, you see that the duration of the query (the time fromwhen the execution phase started) is 4.4 minutes, the query has executed in serial (the fifth columnshows that), and it has consumed only 2.4 minutes of database time. So this indicates that the executing382

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!