A few days ago someone emailed me a Statspack report (10g format) because one of their developers was complaining that “the system” was slow, and they thought this was a little odd because the Statspack report for the period didn’t seem to show any indications that “the system” was suffering from any type of overload.
April 19, 2007
March 7, 2007
One of the ways to use statspack is to extract trending information from the data. I published some sample SQL on my website a couple of years ago to show how this could be done – but there are alternatives.
February 9, 2007
I’ve always been a little nervous about advising people on the snapshot level and snapshot frequency for running statspack.snap(). In general level 0 every 15 minutes seems to be safe, with a slightly more cautious once per hour for levels 5 and above (which, in effect, is the default for the AWR). However, when taking snapshots, it would be sensible to monitor how much work goes into the snapshot so that you can adjust the frequency if you think that statspack itself could be causing some of your performance problems.
January 31, 2007
In an earlier blog [Part 1], I mentioned the 10g view v$event_histogram and described how useful it could be.
If you don’t have the licences that allow you to use the Automatic Workload Repository (AWR) in 10g, you will have noticed that the event histogram has made its way into Statspack for 10g. (more…)
January 14, 2007
There are currently five different levels of statspack snapshots, defined as follows in the table stats$level_description (9i version): (more…)
January 8, 2007
Browsing the Internet recently, I came across the following question in response to a posting by Dan Fink:
Assuming I collect snapshots every 15 min, for example:
January 7, 2007
The output I want to look at in this example doesn’t come from statspack – but it does give you an important reminder about how statspack can deceive because it hides information (by averaging). (more…)
January 5, 2007
I have made a few comments in previous articles about the use of bind variables and some of the peripheral details that can introduce surprises; and in the article on superfluous updates I made a throwaway comment about getting multiple child cursors for a single statement if you had columns of varchar2() or nvarchar2() defined to be longer than 32 bytes. It’s worth expanding on this point.
December 27, 2006
One of the important things to know about the standard statspack report is where not to look. Here’s an example:
Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: 100.00 Redo NoWait %: 100.00 Buffer Hit %: 100.00 In-memory Sort %: 100.00 Library Hit %: 99.96 Soft Parse %: 99.00 Execute to Parse %: 98.02 Latch Hit %: 100.00 Parse CPU to Parse Elapsd %: 92.74 % Non-Parse CPU: 98.56
The Instance Efficiency summary (note especially the indication that 100% is the ideal in all cases) is essentially useless. At least, it is useless in isolation if you run off the occasional report trying to spot problems.
December 3, 2006
The reason for mentioning this particular posting is not specifically its reference to Statspack, it’s for the throwaway comment that Doug uses to explain how he was rapidly able to address the problem highlighted by Statspack:
November 30, 2006
As an aside to comments I’m planning to make on statspack, I thought you might like to look at some of the material written by Tim Gorman about using a statspack repository.
For his collection on whitepapers, including a Powerpoint presentation and Word document on statspack.
And for his collection of scripts, including several that manipulate statspack data.
November 29, 2006
“How do you interpret statspack data ?”
If you go for a generic answer, it’s likely to be a long answer – but the first step is always the classic “Tom Kyte turnaround” … Why do you want to interpret Statspack data ?
As “a starter for ten” [Ed: a reference that may be familiar only to UK viewers of the quiz show Univeristy Challenge], I’m just going to float one thought: there are three reasons for looking at Statspack data and the reason dictates the approach, and the significance you attach to the data.
November 23, 2006
While teaching a session on explain plan and associated technology today, I mentioned the sprepsql.sql script that can be used to report execution plans. At the end of the session one of the attendees asked me if I was aware of a bug with v$sql_plan that could cause the statspack snapshot call to hang the database on a library cache lock until you killed the process.
In fact I was aware of it, but had completely forgotten about it. So at the end of the day I did a quick search on Metalink to see if I could find a reference. It looks like bug 3778541, opened on 20th July 2004, last updated 20th July 2006 (with predicted fix in version 188.8.131.52 – so that looks like a long lifetime for 9.2 ;-)). However this bug is, in fact, reported as fixed in the patch list for 184.108.40.206.
November 15, 2006
A comment on my previous posting about dbms_xplan pointed out that in 10g you also get the function dbms_xplan.display_awr that allows you to report historical execution plans from the AWR (automatic workload repository).
This is true, and there is yet another function dbms_xplan.display_sqlset which allows you to report execution plans from SQL Tuning Sets if you have been using the Automatic SQL Tuning Tools. But to use these functions you do need to purchase the Tuning Pack licence and the Diagnostic Pack licence.