Database Performance Slow

Question

Hi to all,
My database performance is suddenly going slow. My PGA Cahe hit percentage remain in 96%.
I will list out the findidngs I found...
Some tables were not analyzed since Dec2007. Some tables were never analyzed.
(Will the tables were analyzed the performance will be improved for this scenario)
PGA Allocated is 400MB. But till now the max pga allocated is 95MB since Instance started (11 Nov 08 - Instance started date).
(I persume we have Over allocated PGA can i reduce it to 200MB and increase the Shared pool and Buffer Cache 100MB each?)
Memory Configuration:
Buffer Cache: 504 MB
Shared Pool: 600 MB
Java Pool: 24MB
Large Pool: 24MB
SGA Max Size is: 1201.72 MB
PGA Aggregate is: 400 MB
My Database resided in Windows 2003 Server Standard Edition with 4GB of RAM.
Please give me suggestions.
Thanks and Regards,
Vijayaraghavan K

Answer 1

Vijayaraghavan Krishnan wrote:
My database performance is suddenly going slow. My PGA Cahe hit percentage remain in 96%.
Some tables were not analyzed since Dec2007. Some tables were never analyzed.
PGA Allocated is 400MB. But till now the max pga allocated is 95MB since Instance started (11 Nov 08 - Instance started date).
(I persume we have Over allocated PGA can i reduce it to 200MB and increase the Shared pool and Buffer Cache 100MB each?)
You are in an awkward situtation - your database is behaving badly, but it has been in an unhealthy state for a very long time, and any "simple" change you make to address the performance could have unpredictable side effects.
At this moment you have to think at two levels - tactical and strategic.
Tactical - is there anything you can do in the short term to address the immediate problem.
Strategic - what is the longer-term plan to sort out the state of the database.
Strategically, you should be heading for a database with correct indexing, representative data statistics, optimium resource allocation, minimum hacking in the parameter file, and (probably) implementation of "system statistics".
Tactically, you need to find out which queries (old or new) have suddenly introduced an extra work load, or whether there has been an increase in the number of end-users, or other tasks running on the machine.
For a quick and dirty approach you could start by checking v$sql every few minutes for recent SQL that might be expensive; or run checks for SQL that has executed a very large number of times, or has used a lot of CPU, or has done a lot of disk I/O or buffer gets.
You could also install statspack and start taking snapshots hourly at level 7, then run off reports covering intervals when the system is slow - again a quick check would be to look at the "SQL ordered by .." sections of the report to the expensive SQL.
If you are lucky, there will be a few nasty SQL statements that you can identify as responsible for most of your resource usage - then you can decide what to do about them
Regarding pga_aggregate_target: this is a value that is available for sharing across all processes; from the name you've used, I think you may be looking at a figure for a single specific process - so I wouldn't reduce the pga_aggregate_target just yet.
If you want to post a statspack report to the forum, we may be able to make a few further suggestions. (Use the "code" tags - in curly brackets { } to make the report readable in a fixed fontRegards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The temptation to form premature theories upon insufficient data is the bane of our profession."
Sherlock Holmes (Sir Arthur Conan Doyle) in "The Valley of Fear".