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. Every time I’ve done an exercise like this the response from the technical group has been very positive, and quite often their management has reported back an increased enthusiasm for problem-solving from their teams.
I’ve even found that when I go on site for one or two days in a pure trouble-shooting role and spend time with just one or two DBAs, they often end up commenting that the ideas and insights that come up in our conversation about the problems are more instructive than seeing the solution itself.
If you’d like to get me on site for an open-ended day where you can really see how trouble-shooting can be done, then drop me an email.