Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: Interpretation of Statspack reports

Re: Interpretation of Statspack reports

From: andreik <>
Date: Wed, 22 Aug 2007 13:09:37 -0000
Message-ID: <>

On Aug 22, 2:27 pm, Helma <> wrote:
> Hello all,
> I'm new into reading statspack reports, and i would like to hear your
> opinion on some findings i find odd.
> It's a 1hour snapreport from an oracle 9 on a 2CPU windowsmachine with
> one thirth-party application and a handful of users. Dataloading is
> about 1Gb per day.
> There are a couple of weird choices made with the application design,
> e.g. every table has it's own tablespace, so there are more than 900
> tablespaces with over 1800 datafiles. There are only a few users, the
> database is configured as shared server. etc!

This is really interesting :) I hear of such design for a first time. Each table in it's own tablespace, interesting. I wonder who could come up with such an idea?? :) It's no doubt you would have problems with such a system... by the way, what problems do you have exactly? It seems you forgot to tell us.

> Anyway:

> Q1:
> This application primarily loads data , although i suspect in a
> suboptimal way. I would have
> expected that I/O would be the main timed event, not the CPU. Does
> this confirm that the procedure that processes and loads the data is
> suboptimal?

CPU time event is not a "wait". It shows how much time has user sessions spent on the CPU. So 1400 seconds during an hour (considering 2CPUs thats 700s per CPU) is quite an idle system.

> Q3: What book / article do you advice to learn the fine art of
> reportreading? Most of the things i found are rather basic - how to
> create a report, add statspack jobs, etc.
> TIA,
> H.


You could read the Tuning Guide, and specifically the "instance tuning steps", here: It could explain a lot.

You could also upload a full statspack report, preferably of level 7, someone might even be able to read it here :)

Received on Wed Aug 22 2007 - 08:09:37 CDT

Original text of this message