Hi,
I agree with Daniel, throwing more memory at the database does not necessary
mean it will perform any better. I am currently supporting around 10
databases on Windows 2000, and the largest SGA is around 1GB. We've tested
really big SGA's (Up to 5GB) but we did not receive any SIGNIFICANT
performance gain by having it set so large.
Just from what I've seen, I have the following comments:
- Why is your shared pool so large? I know this is something that varies
from environment to environment but 600MB is extremely large. Remember, this
is a cache for SQL statements so unless you have gigantic SQL statements
being thrown at your system, it does not have to be so large. You may
actually have this in reverse, in that your buffer cache is only around
100MB. Try and find a balance by lowering the shared pool and increasing the
buffer cache.
- From your top wait events, db file sequential read is tops. This normally
points to index scans. Are you running a packaged app or something developed
in-house. Again, this is dependant on your environment.
- Finally, you've provided a STATSPACK report that is fairly old and does
not span a great deal of time. I would recommend looking at more recent
data, and making comparisons between different periods of activity on your
system.
Regards
P.S. What is your disk configuration like? Size of DB?
Received on Fri May 28 2004 - 08:49:16 CDT