Expert Oracle Exadata - Parent Directory

CHAPTER 12 MONITORING EXADATA PERFORMANCEyou can report what these exact database sessions were doing when a user experienced unacceptableresponse times. Note: We deliberately said unacceptable response times here instead of just “user experienced performanceproblems.” Whenever anyone complains about a performance problem, you should clarify what they actually meanby that and how it was measured. Does any user actually experience far too long response times in theirapplication, or did some monitoring system merely raise an alarm about “too high” CPU utilization or any othersecondary metric like that? Your subsequent actions would depend on the problem you’re trying to solve. Ideally,you should not use a performance tool or Oracle metric for determining whether you have a performance problem.Your starting point should be the users (who report a problem) or application-level metrics, which see the databaseresponse time from the application perspective. No matter how good the database metrics look, if the applicationwaits for the report completion for ages, you have a performance problem to drill down into. Conversely, no matterhow “bad” your database metrics seem to be, if your application response times are satisfactory, you don’t havean acute need to start fixing anything.When examining performance metrics because of an ongoing problem (of too long response times), youshould start by identifying the sessions servicing this slow application or job and then drilling down intothat response time. It would be more correct to call this performance troubleshooting, not justmonitoring.Note that there are other kinds of performance monitoring tasks, which you may want to do—forexample, proactive utilization and efficiency monitoring. Performing these tasks allows you to keep aneye on the utilization headroom left in the servers and detect any anomalies and sudden spikes insystem utilization and low-level response times, possibly even before users notice a response timedifference. Yet another reason for collecting and monitoring performance and utilization data is forcapacity planning—but capacity planning is outside the scope of this book. Also, because this is adatabase book, we won’t dive into any end-to-end performance measurement topics, which wouldinvolve identifying time spent in application servers, on the network, and so on.We will start by looking at how to identify where a long-running query is spending most of its time.We’ll also look at how to tell whether a query is taking full advantage of Exadata’s performance features.Monitoring SQL Statement Response TimeThe best tool for monitoring long-running queries is Oracle 11g‘s SQL Real Time monitoring page. It isable to gather all the key performance information onto a single page, even in the case of parallelexecution across multiple RAC instances.The SQL Monitoring feature requires you to have a Diagnostics and Tuning Pack license. SQLMonitoring kicks in automatically if you run your query with parallel execution or when a serial queryconsumes more than 5 seconds of I/O and CPU time in total. Additionally, you can control themonitoring feature with MONITOR and NO_MONITOR hints. If you want to monitor your frequently executedshort-running queries, the best tool for this would be to use ASH data and list the top wait events and toprowsources from there (using the SQL_PLAN_LINE columns in the V$ACTIVE_SESSION_HISTORY view).If you are already aware of a performance problem (perhaps your users are already complaining oftoo long response times), then you should use a top-down approach for monitoring. You should identify380