Tuning a Monster

[Yogeeraj_1]

hi again,

STATSPACK
=========
You should be using statspack on a constant basis.

Every morning, you should take a snapshot, every afternoon another, every evening, yet another.

Now you have a history. You can compare a statspack from today (bad performance) with last weeks at the same time (good performance) and look for major differences.

Also, people must "quantify" things. Eg: Screen 1 typically takes less then 1 second, today it is taking 60 seconds. -- Ah ha, maybe we lost an index on some of the tables surrounding screen 1, lets look at that. Are there specific components "going slow" or is the entire thing going slow.

Statspack will help you identify the top sql, the big wait events, contention points, bad performance metric (eg: the soft parse ratio is my personal favorite).

Also, attack this from two points - get the SA's looking at the machine, network, disks, etc.

As it is now, if you don't have a history of what "good" looks like - it is REALLY REALLY hard to figure out "badness". You need to gather more information, isolate the issue if possible and go from there.

If you need any further help, let us know.


Regards
Yogeeraj

[Steven E. Protter]

Let me chime in and say dbc_max_pct is a big possible problem.

I'm attaching a data collection script for you to measure performance over time.

SEP