Of course, the exciting part for me was sitting down with a batch of Statspack and AWR reports that I had been supplied with in the previous couple of days and doing a “real-time” analysis of them.
I’m not sure that I’ve got the balance quite right doing this – the first time I did it for a SIG some of the feedback suggested that it would have been better to say less about each report and work through more reports; and that’s what I tried this time – but I felt that I barely touched on the information that was available in each report. Next time, I think I’ll pre-select just three reports and give each one about 20 minutes.
When I do this type of thing on a client site, of course, it’s in front of a small group (usually about 6 to 15) of DBAs or developers, with their production system up on the big screen. This has three major benefits:
- It’s their system, so they recognise the activity that the report is talking about, which makes it easier for them to relate to the type of problems and symptoms we see, and we can spend the time where it’s really helpful.
- It’s their site, their database and their group (and it’s a small group), so it’s much easier to get a discussion going about where the problems are coming from, and how realistic different solutions might be.
- It’s a live database so it’s possible to pursue the problem right down to the root cause (and sometimes fix it – or supply the correct fix – immediately). This is an activity that takes us through the whole range of analysis: from symptoms to SQL, to execution plan, to indexing, to data analysis, to optimising SQL, and so on.
If you’ve got a group of DBAs (or developers who want to get more involved with problem solving) this is a really good way to improve their trouble-shooting skills and sort out a few performance problems at the same time.
If you’d like to get me on site for an open-ended day where you can really see how trouble-shooting should be done, then drop me an email.