Expert Oracle Exadata - Parent Directory

CHAPTER 12 MONITORING EXADATA PERFORMANCENAME INVERSE VERSION-------------------- -------------------- ---------------NO_MONITORING 8.0.0MONITOR NO_MONITOR 11.1.0.6NO_MONITOR MONITOR 11.1.0.6Note that the NO_MONITORING hint is something completely different despite the similar name. TheNO_MONITORING hint allows you to disable the predicate usage monitoring on table columns(sys.col_usage$), and it has nothing to do with the Real-Time SQL Monitoring option introduced inOracle 11g.Monitoring SQL Statements using V$SQL and V$SQLSTATSThe performance monitoring in the “olddays” before-Oracle 10g ASH was usually done using various V$views, which showed aggregated instance-wide metrics. For example, the Statspack’s TOP-5 wait eventsreport section was just a delta between two V$SYSTEM_EVENT view snapshots. The TOP SQL reports werebased on V$SQL snapshots, which externalize the execution statistics and resource consumption for eachchild cursor still in library cache. However, in a large database system (think e-Business Suite or SAP),you can have tens of thousands of cursors in the library cache, so gathering and storing deltas of all oftheir stats is not feasible. That’s why tools like Statspack and AWR store deltas of only some topresource-consuming statements and ignore the insignificant ones. Remember that as these tools gatherinstance-wide data, they may end up ignoring a long-running statement if there are only a few sessionsexecuting it. A single session running a bad SQL statement may not be “heard” in the noise of all theother sessions in the instance—potentially thousands of them. This instance-wide scope performancedata analysis is not as powerful as the session-level ASH data slicing and dicing. With ASH you can drilldown into any single session, regardless of how many sessions in total you have making noise in theinstance.If you use Exadata, you must be running at least Oracle 11g R1 on it, so all these superior tools areavailable, assuming that you have the Diagnostics and Tuning Pack licenses for your Exadata cluster. Bythe way, we haven’t seen an Exadata-using customer without Diagnostics and Tuning Pack licenses yet,so it looks like the vast majority of Exadata users do not have to resort to old tools like Statspack or createa custom ASH-style repository themselves (although it’s easily doable with a few lines of PL/SQL codepolling V$SESSION or its underlying X$KSUSE view in each instance).The V$SQL and V$SQLSTATS views still do have some advantage over SQL Monitoring and ASH-stylesampled data in a few cases. For example, if you want to measure metrics like the number of executions,buffer gets, parse calls, fetches, or rows returned by the SQL child cursor, you can get this data from bothReal-time SQL Monitoring (V$SQL_MONITOR) or the V$SQL/V$SQLSTATS views, but not ASH. But the problemwith SQL Monitoring is that it doesn’t monitor short-running queries at all, therefore making it unusablefor keeping track of OLTP-style small queries executed many times per second. Even adding a MONITORhint into every query of your application would not help, as the maximum number of monitored plans islimited (controlled by the _sqlmon_max_plan parameter, which defaults to 20 plans per CPU) and youwould likely end up with real-time plan statistics latch contention as well. The SQL Monitoring feature isnot meant to monitor short-running queries executed many times per second.And this leaves us with V$SQL and V$SQLSTATS. They both maintain similar data, but they areinternally different. Whenever you query V$SQL without specifying an exact SQL_ID, Oracle has to traversethrough every single library cache hash bucket, and all cursors under it. This may contribute to librarycache mutex contention if you have a busy database and lots of cursors in the library cache, becausewhen you traverse the library cache structure and read its objects’ contents, you’ll have to hold a mutexon the object. Note that starting from Oracle 11g, all library cache latches are gone and are replaced by393