ExaSnapper 0.7 beta download and the hacking session videos

Thank you for attending the Exadata Snapper (ExaSnapper) hacking session!

I have split the recording of this session into 3 pieces and uploaded to enkitec.tv. The ExaSnapper beta that I demoed is also available now in my blog. See the links below.

For quick reference, here’s the syntax of running ExaSnapper – there are two modes, one is the before/after capture (think Tom Kyte’s runstats, but for exadata metrics) and the other is more like a DBA-monitoring mode, where you can just measure a few seconds worth of a long-running query runtime and get the IO and efficiency figures from there.

No, direct path reads/writes for workarea spilling to temp are not offloaded (however it’s worth noting that smart scans can be done on GTTs too).

As far as query execution goes, the only thing that can get offloaded is the *data retrieval* from the segment blocks. In other words the TABLE ACCESS STORAGE FULL row source (and a few similar ones against different segment types). Any sorting, hashing, grouping, joining etc does not get offloaded. When hash joins “get offloaded” thanks to bloom filter pushing to storage cells, it’s not really the joining operation that gets offloaded, but the *data retrieval* from the probed table can filter even more rows out in the cell, thanks to the bloom filter.

If your question was prompted thanks to the slide I posted here – this slide is not only about offloading and smart scans. It’s about the *total amount of IO* your session is doing for different reasons – and ExaSnapper allows you to break down what consumed the most IO.