People frequently ask questions about interpreting statspack (and AWR) outputs. So I’ve started to collect references to examples of statspack (and AWR) outputs that have been published on the Internet with intelligent comments about interpretation. A few of the items are about related topics, rather than output and interpretation.

There are bound to be more items out there than I currently know of, so if you know of any good examples, add it to the comments list and if I like it I’ll add it to the main list.

Getting Started: if you don’t know how to install or use statspack, then the best place to start is on your server by reading the documentation at $ORACLE_HOME/rdbms/admin/spdoc.txt, which describes how to install it, how to take snapshots, and how to use the reporting facilities.

The papers at the top of the list from Connie Dialeris Green and Graham Wood seem to drift around as Oracle Corp. re-organizes the TechNet website. At present they are in the “database/focus-areas” directory.

If the current links fail for you, please add a comment so that I can find and relink them.

Jonathan,
I recently installed 12c (database) and I’m trying to install statspack. Do you have any insight on the install, particularly around common and local users, and where perfstat would set in this pantheon? Other things to be aware of in this plugable environment for running statspack?
Thanks,
bg

I hadn’t thought of trying to install statspack on 12c.
Following your comment I’ve taken a quick look at $ORACLE_HOME/rdbms/admin/spdoc.txt and noted a small reference to 12c (which, at the head of the document, calls it 12g ;) )

So there have been some changes for 12c.
There’s also this pair of lines in the spcreate.sql script, although I can find anything in any of the other scripts that relates to it – so perhaps it an internal fiddle to handle the issues of how links between plugged databases and the container database are made.

-- set this parameter for creating common objects in consolidated database
alter session set "_oracle_script" = TRUE;

What sort of problems are you seeing, and what type of install are you doing.

I’ve just done an install into EE without containers; all I did was create a tablespace for the perfstat account, comment out the “_oracle_script” line, and then run spcreate.sql as sys. I’ve taken a couple of snapshots, and produced a report,

Everything seemed to work okay; the only problem was that every wait in my Top 5 looked as if it should have been listed as idle – here’s the list, with their probable timeouts:

The spcreate.sql runs to completion and spauto.sql will run and set up the job.

Now the question is what is statspack sampling activity against — the container pdborcl or against all of the database? Given perfstat’s privileges and roles, I’m guessing all of the database. Hum …? Not straight forward.

Might be interesting to globally change perfstat to c##perfstat in the statspack creation scripts and see what happens.

That’s what I did when I got to a CDB. The snapshot will be for the container, since there is only one library cache, SGA, etc… But that’s the way the AWR works anyway. The interesting thing is what happens when the specific PDB is closed but the CDB is up with a job visible in cdb_jobs.

I did consider messing about with a c##perfstat, but there were a lot of places I’d have to fiddle with the sp scripts.

Bill,
Latest update: edit spcusr.sql to comment the line “container=current” in the ‘create user’ statement; execute the “alter session” command from the spcreate.sql script running the script, and you can install perfstat as a common user in the CDB$ROOT.

The gap in the snap id is a relatively common phenomenon. The sequence used by statspack has a cache size of 10, so if it gets flushed out of the library cache you can lose values. I’ve often suggested to people that they change to nocache on that sequence to avoid losing values (this allows you to cheat a little bit with “difference” SQL). On the other hand if you leave the cache at 10 it can give you a little threat warning that you have pressure on the shared pool if you see some sort of persistent pattern of gaps (e.g. the snap_id jumps by 10 between 8:30 pm and 10:15 pm, but doesn’t have gaps at any other time of day).