I have fixed most of the bugs that showed up during the Snapper launch party session and uploaded the new version (v4) of Snapper here:
I have also uploaded the launch party hacking session video to enkitec.tv:
I have not updated the snapper documentation yet, but here are the main improvements:
- RAC support (query remote instance’s sessions performance data via GV$)
- Manually taken “before” and “after” snapshot support. No need to use DBMS_LOCK to sleep for a certain number of seconds between snapshots
- Useful averages in the right side of the output (e.g. average bytes sent/received per roundtrip etc). I will keep adding new averages over the coming weeks.
I have kept the syntax backwards-compatible, so when you run Snapper like this …
@snapper ash 5 1 user=tanel
… it will still query only local instance’s sessions.
But if you want to measure all tanel’s sessions in let’s say instance #2 only, you can just add @2 to the session filter condition:
@snapper ash 5 1 user=tanel@2
Or if you want all instances then use @*:
@snapper ash 5 1 user=tanel@*
If you want to measure a single session with sid 1234 in instance #2, you can do it in two ways:
@snapper ash 5 1 1234@2
Or use the inst_id,sid tuple syntax:
@snapper ash 5 1 (2,1234)
Note that the brackets are important, as otherwise snapper thinks that you want to measure SID 2 and SID 1234 in the local instance. You can pass multiple inst_id,SID tuples to the snapper though:
@snapper ash 5 1 (2,1234),(4,5678),(3,999)
Snapper still supports the qc= syntax too, to list all sessions started by a PX query coordinator session:
@snapper ash 5 1 qc=1234@*
Note that the qc= syntax is a bit broken/inconsistent right now – what the qc=1234@* means right now is that Snapper looks up the SID 1234 from every instance and lists slave sessions from all instances. If you use qc=1234@2 for example, then Snapper would only look for QC in the instance #2 and any slaves that are also in instance #2 (but with inter-instance parallelism you may have slaves in other instances too). I will fix it in a near-future version.
I will write about the other major features in separate blog entries, but if you want to learn about it now, then grab a beer (or coffe) and watch the latest enkitec.tv show (it’s a bit over 2 hours :-))
P.S. Snapper 4 is still beta! Some queries (like the qc=) one may take a while to run, running dynamic queries with subqueries against GV$ views efficiently is tricky business. This is why I have kept the old snapper v3 (which is more stable and pretty efficient) in the standard (old) snapper address.
Update: If you want to see what Snapper is capable of (it’s about the old version 3), check this document about using Snapper for Oracle performance measurement.
NB! If you want to move to the "New World" - offload your data and workloads to Hadoop, without having to re-write your existing applications - check out Gluent. We are making history! ;-)