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 11 UNDERSTANDING EXADATA PERFORMANCE METRICScell physical IO interconnect bytesThis is a simple, but fundamental statistic, which shows how many bytes worth of any data have beentransmitted between the storage cells and your database sessions. This includes all data, both sent andreceived by the database, the Smart Scan result sets, full blocks read from the cells, temporary I/O readsand writes, log writes (if LGWR), any supplementary iDB traffic, and so on. So, this statistic shows alltraffic bytes, regardless of its direction, contents or nature.When measuring the write I/O metrics, don’t be surprised when you see that the cell physical IOinterconnect bytes statistic is two or three times higher than the physical write total bytes statistic. This isbecause the latter statistic is measured at the <strong>Oracle</strong> database level, but the cell physical IO interconnectbytes is measured at the cell level, after ASM mirroring has been done. So if, for example, LGWR writes1MB to an ASM disk group with high redundancy (triple mirroring), a total of 1.5 MB of data would besent over the interconnect. Note that there is a bug (#10036425) in <strong>Oracle</strong> 11.2.0.1 that increments thisstatistic even on non-<strong>Exadata</strong> databases, so you can just ignore it on non-<strong>Exadata</strong> databases.cell physical IO interconnect bytes returned by smart scanThis statistic is an important one and shows how many bytes of data were returned to the database layerby the Smart Scan. The bytes actually returned should be much less than the bytes scanned / read fromdisk. This is the main point of the <strong>Exadata</strong> Smart Scan feature— the cells may read gigabytes of dataevery second, but as they perform early filtering thanks to predicate offloading, they may send only asmall part of the rows back to the database layer. Additionally, thanks to the projection offloading, theSmart Scans only return the requested columns back, not full rows. Of course, if the application usesSELECT * for fetching all the columns of a table, projection offloading would not help, but the earlyfiltering thanks to predicate offloading can still help a lot.This statistic is a subset of the cell physical IO interconnect bytes statistic, but it counts only the bytes(of row sets) that are returned by Smart Scan sessions and no other traffic.cell scansThis statistic is just like the cell index scans, but cell scans shows the number of Smart Scans done ontable and materialized view segments. With serial execution, this statistic is incremented once in thebeginning of every segment scan. So when scanning through a partitioned table, in which each partitionis a separate segment, this statistic would be incremented for each partition. With parallel scans, the cellscans statistic will increment even more, as parallel slaves perform their scans on block ranges (PXgranules) handed over to them by the query coordinator— so the scan on each block range is reported asa separate cell scan. The presence of the table scans (rowid ranges) statistic indicates that PX scans onblock ranges are happening.Following is an example of a parallel full table scan session’s statistics (with two slaves). The133.8GB table was apparently “split” into 132 rowid ranges and scanned using Smart Scans and thanksto the Smart Scan’s offloading features, only 4.54GB worth of resulting data had to be sent to thedatabase.368

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

Saved successfully!

Ooh no, something went wrong!