Statspack is the most vicious, foul waste of time, breath and manpower.
It is truly terrible and is a disgrace to all technical and
professional efforts working with Oracle. Next time I lose my keys,
I'll make sure I check Google satelite maps.

t_pascal@my-deja.com wrote:
> Statspack is the most vicious, foul waste of time, breath and manpower.
> It is truly terrible and is a disgrace to all technical and
> professional efforts working with Oracle. Next time I lose my keys,
> I'll make sure I check Google satelite maps.

StatsPack is wonderful ... for those that invest time in learning
it. Not as nice as AWR but a lot better than stumbling around in
the dark.
--
Daniel A. Morgan
http://www.psoug.org
damorgan@x.washington.edu
(replace x with u to respond)

DA Morgan wrote:
> t_pascal@my-deja.com wrote:
> > Statspack is the most vicious, foul waste of time, breath and manpower.
> > It is truly terrible and is a disgrace to all technical and
> > professional efforts working with Oracle. Next time I lose my keys,
> > I'll make sure I check Google satelite maps.
>
> StatsPack is wonderful ... for those that invest time in learning
> it. Not as nice as AWR but a lot better than stumbling around in
> the dark.
>
Statspack will only give you system-level problems. It will not find
anything smaller than a city square block. Stumbling in the dark,
waving around your fake flashlight is not the answer.

Statspack has it's place. It is good for gathering systemic
information, identifying those types of issues. It is also good as a
historical reference, especially when you write your own queries to
extract relevant data.

Will it identify a specific user complaint? Probably not, that is where
extended sql_trace comes in to play.

The key to using a tool is to use it appropriately and to understand
what it can't do for you.

Regards,
Daniel Fink

http://www.blogger.com/comment.g?blo...61500855200 3

I think people with experience tuning systems underestimate how
generally out of tune some systems can be. You need to get into the
ballpark before you can get close to finding your keys.

I don't use statspack though, since I usually fix the obvious-to-me
problems first, in a non-methodological manner (which comes
surprisingly close to some methodologies - the low-hanging fruit is
often quite similar to ordering business costs, but leaves me feeling
in more control of technical recommendations, an important point in
businesses that think they are not technology driven). But I would
recommend a proper methodology for most people, which includes the two
Daniels answers.

jg
--
@home.com is bogus.
Hypengyophobia - fear of responsibility

Hi Dan.

When I really want to hang a 10g R1 database instance on win32
(10.1.0.4, even with patch 9 applied) gathering a level 7 statspack
snapshot will do it.

I hope to have enough time next week to open the iTAR - but for now its
sitting in the bucket of "Don't do that". I've seen this before, its
probably "fixed in 10.2".

(it was the insert into stats$sql_plan that threw the ora-7445)

-bdbafh

On 25 Jan 2006 10:30:47 -0800, t_pascal@my-deja.com wrote:

>Statspack will only give you system-level problems. It will not find
>anything smaller than a city square block. Stumbling in the dark,
>waving around your fake flashlight is not the answer.

As you can run statspack on session level, I don't think this is true.

--
Sybrand Bakker, Senior Oracle DBA