Expert Oracle Exadata - Parent Directory

CHAPTER 12 MONITORING EXADATA PERFORMANCEmutexes. These same mutexes are used for parsing, looking up, and pinning cursors for execution, so ifyour monitoring queries poll V$SQL frequently, they may end up causing waits for other sessions.The V$SQLSTATS view, which was introduced in Oracle 10gR2, doesn’t have this problem. Startingfrom Oracle 10gR2, Oracle actually maintains SQL execution statistics in two places— inside the childcursors themselves (V$SQL) and in a separate cursor statistics array stored in a different location in theshared pool. This separation gives the benefit that even if a cursor is flushed out from the shared pool, itsstats in this separate array may remain available for longer. Also, when monitoring tools queryV$SQLSTATS, they don’t have to scan through the entire library cache, thanks to the separate array wherestats are stored. This means that your monitoring tools won’t cause additional library cache latch (ormutex) contention when they use V$SQLSTATS instead of V$SQL. Both Statspack and AWR do useV$SQLSTATS to collect data for their top SQL reports.Let’s look into V$SQLSTATS (the V$SQL view has pretty much the same columns, by the way). Some ofthe output here is removed to save space:SQL> @desc v$sqlstatsName Null? Type------------------------------- -------- ----------------------1 SQL_TEXT VARCHAR2(1000)2 SQL_FULLTEXT CLOB3 SQL_ID VARCHAR2(13)...6 PLAN_HASH_VALUE NUMBER...20 CPU_TIME NUMBER21 ELAPSED_TIME NUMBER...26 USER_IO_WAIT_TIME NUMBER...33 IO_CELL_OFFLOAD_ELIGIBLE_BYTES NUMBER34 IO_INTERCONNECT_BYTES NUMBER35 PHYSICAL_READ_REQUESTS NUMBER36 PHYSICAL_READ_BYTES NUMBER37 PHYSICAL_WRITE_REQUESTS NUMBER38 PHYSICAL_WRITE_BYTES NUMBER...41 IO_CELL_UNCOMPRESSED_BYTES NUMBER42 IO_CELL_OFFLOAD_RETURNED_BYTES NUMBERThe highlighted rows starting, with IO_CELL, are metrics related to Exadata storage cells (although theIO_INTERCONNECT_BYTES is populated on non-Exadata databases as well, thanks to a bug). You wouldwant to compare these cell metrics to database metrics (like physical_read_bytes) to understandwhether this SQL statement is benefitting from Exadata Smart Scan offloading. Note that these metrics,which merely count bytes, should not be used as the primary metric of performance ; again, the primarymetric, the starting point, should always be response time, which you can then break down intoindividual wait events or into execution plan rowsource activity (with the SQL Monitoring report orASH). You can learn more about the meaning of the metrics shown here in Chapter 11.Note that even though the V$SQLSTATS view also contains the PLAN_HASH_VALUE column, it actuallydoes not store separate stats for the same SQL ID with different plan hash values. It aggregates all thestats generated by different plans of the same SQL ID under a single bucket. So you don’t really knowwhich plan version consumed the most resources from this view. Luckily in Oracle 11.2 there is a new394