SEO

#1 (**permalink**) 02-26-2008, 05:38 PM

My database is suffering from poor performance of late. Reports that
used to run in a reasonable time, now take a while. The explain output
show that the query is fully indexed, and the statistics are up to
date. Using a statement monitor I was able to determine that a
particular query took 545 seconds of real time to run, yet only 19
seconds of CPU. According to my system monitoring tools, I had plenty
of idle CPU cycles and free memory laying around, and I/O was normal,
so the box was not at capacity during the execution of the query. I
didn't see any query waiting on locks using the lock monitoring
facilities. What other things can I look for to get to the bottom of
this? Platform is AIX 4.3 and UDB 7.2 FP8.

Thanks,
Evan

#2 (**permalink**) 02-26-2008, 05:38 PM

"Evan Smith" <esmith2112@hotmail.com> wrote in message
news:23658335.0404011550.551ff99d@posting.google.c om...
> My database is suffering from poor performance of late. Reports that
> used to run in a reasonable time, now take a while. The explain output
> show that the query is fully indexed, and the statistics are up to
> date. Using a statement monitor I was able to determine that a
> particular query took 545 seconds of real time to run, yet only 19
> seconds of CPU. According to my system monitoring tools, I had plenty
> of idle CPU cycles and free memory laying around, and I/O was normal,
> so the box was not at capacity during the execution of the query. I
> didn't see any query waiting on locks using the lock monitoring
> facilities. What other things can I look for to get to the bottom of
> this? Platform is AIX 4.3 and UDB 7.2 FP8.
>
> Thanks,
> Evan
Can you post the query, table.index DDL, and the explain output? Also need
size of tables and size of expected result set.

When you say "used to run in a reasonable time" what do you mean (compared
to the 9 minutes of the recent query)?

There are many other things that can affect performance such as runstats
(full stats), bufferpools, prefetch, tablespace/container configuration,
disk configuration, etc.

Also very important is the system temporary tablespace(s), which should be
at least as large as the largest table, and preferably several times larger
if multiple simultaneous queries are running. If this tablespace is
constrained by available disk space (SMS), or defined too small (DMS), this
can cause noticeable performance problems.

Also look for sort overflows on a snapshot that can be an indication that
sort heaps need to be increased.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Poor Performance: High Real Time/CPU Time Ratio