Performance problem in 9.2.0 database

Question

Hello All,
Database : 9.2.0.7
Os : windows 2003 sevrer standdard edition
RAM 4 Gigs
The buffer cache hit ratio in this server is around 83%, where it normaly was around 98% before i did some maintenance activities.
I have done some maintenance activities in January on this database.
Maintenance activties includes below steps
1.In production i have deleted old data in the production tables
2.Reorganized tablespaces,tables
3.Rebuild indexes for those tables.
4. At last collected statistics for those tables.
Now after this activity the buffer cache hit ratio is very low.
Any one please advice on how to increase the hit ratio.
TIA,

Answer 1

ORCLDB wrote:
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
CPU time                                                        7,029    55.87
PX Deq: Signal ACK                                 77,056       1,950    15.50
db file sequential read                         6,119,051       1,302    10.35
db file scattered read                          3,544,645       1,054     8.38
log file sync                                     127,427         551     4.38
How long was the snapshot interval ?
How many CPU in the machine ?
How many users to you have to support ?
Is your operating system 32 bit or 64 bit ?
Is this an OLTP system or a datawarehouse / DSS type of system ?
First thoughts
You probably have some changes in execution plans because you made some objects smaller and more densely packed - leading Oracle to think that tablescans and index fast full scans would be efficient. (This is a GUESS base on the large number of "db file scattered read" and the assumption that this is NOT a data warehouse).
You probably have a large amount of spare RAM (your machine has 4GB, your cache is 300MB) and should increase the size of the cache. (This is a guess based on the fact that your db file reads are averaging less than 0.3 milliseconds so are almost sure to be coming out of a local filesystem cache.) The change may decrease the amount of CPU you are using, because all that copying between caches will be using CPU.
The parallel execution probably needs to be stopped (based on your comments to another user about rebuilding indexes in parallel) because this can result in lots of tablescans and index fast full scans - which aren't necessarily going to use direct path reads because Oracle may be doing tablescans that go "serial to parallel". Set the suspect indexes back to "no parallel".
For confirmation about where the time goes - check the "SQL Ordered by Reads" section of the report and look at the execution paths of the top two or three SQL statements. (Note: if you set statspack to take snapshots at level 6, you can usually get the actual execution plans of the top SQL by running the srcipt $ORACLE_HOME/rdbms/admin/sqrepsql.sql
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
A general reminder about "Forum Etiquette / Reward Points": http://forums.oracle.com/forums/ann.jspa?annID=718
If you never mark your questions as answered people will eventually decide that it's not worth trying to answer you because they will never know whether or not their answer has been of any use, or whether you even bothered to read it.
It is also important to mark answers that you thought helpful - again it lets other people know that you appreciate their help, but it also acts as a pointer for other people when they are researching the same question, moreover it means that when you mark a bad or wrong answer as helpful someone may be prompted to tell you (and the rest of the forum) what's so bad or wrong about the answer you found helpful.