Solved

BUFFER CACHE HIT RATIO - below 70%

Posted on 2010-11-24
12
741 Views
Last Modified: 2012-05-10
Hi experts,
Good morning.
We added one more processor in the server during the weekend.  Since then the performance is affected, i increased the SGA to 1.8 GB from 1.2 GB.  The buffer cache hit ratio is still showing below 70%.  Especially when we do the search from the application and navigating from one page to another page, it takes more than 6 sec whereas it was not the case earlier.

Regards
S Govindarajan
0
Comment
Question by:itdubai
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 2
  • 2
  • +3
12 Comments
 
LVL 7

Expert Comment

by:jocave
ID: 34210756
Since you are using 9.2, do you have a Statspack report from before and after the upgrade?  Do you see any queries whose elapsed time has increased?  My guess without more data is that some query plan changed but a Statspack report will be far more definitive than a guess.
0
 
LVL 7

Expert Comment

by:MrNed
ID: 34210761
Has it been a long time since you restarted? Maybe you changed a parameter in memory only which has been lost on reboot. I cant remember 9.2 much but did it log the parameter settings in the alert log each time the instance started - maybe you can double check in there.
0
 

Author Comment

by:itdubai
ID: 34210884
Hi iocave,
i do not have statspack report.   However i will check the statspack report and give you more information.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 

Author Comment

by:itdubai
ID: 34210886
Hi MrNed:
The server is restarted during the weekend after adding the processor.  Also when i changed the memory yesterday, i restarted the database and verified that the changes are taken place.  In the alert log, it is clearly mentioned that the memory settings are changed.
Regards
0
 
LVL 7

Expert Comment

by:MrNed
ID: 34210903
I meant if it hasn't been restarted in say 6 months, have you changed any parameters where scope=memory only without updating the (s)pfile as well? Then when you restarted on the weekend, those changes were lost.
0
 

Author Comment

by:itdubai
ID: 34210922
Hi MrNed:
No.  I have not done any changes in the recent times.  It was working fine without any issue.
0
 
LVL 5

Expert Comment

by:manzoor_dba
ID: 34211416
Hi,

Hope this could be reason... once you have restarted your database your shared pool will get flushed and all the queries has to do a hard parsing for a whiile , hard parsing will consume cpu and takes time.  Also you have added one CPU not the RAM, but you have increased the size of SGA, so extra memory has been alloted to SGA with no increase in the RAM size....

Thanks..

0
 

Author Comment

by:itdubai
ID: 34212088
Hi Manzoor,
Thanks for your solution.  But i could not understand what you are trying to say. The server is having 8 GB Ram + 2 CPUs on Windows 2003 32 bit.  
regards
0
 
LVL 11

Expert Comment

by:Akenathon
ID: 34213248
Ratios won't show you the path to performance, especially a single isolated one. In any case, they are just symptoms. To solve any performance problem you need to understand the root cause.

Now, if you don't have historic data (before the changes took place), it's useless to concentrate on the fact that "it used to run faster". Start diagnosing as if this were the first time you get your hands on this scenario and you will soon get somewhere.

A good place to start would be a statspack report showing a 15 to 30 minute interval, when the response times are as bad as they possibly can. Please attach such report to help you further, since there's nothing we can do for you without digging deeper.
0
 

Author Comment

by:itdubai
ID: 34225118
I took a statspack report today.  Attached herewith.  Could not locate the issue yet.  Please help.
spreport-odb1-298-319.lst
0
 
LVL 7

Accepted Solution

by:
jocave earned 250 total points
ID: 34225189
First off, it's not clear that the database is the bottleneck.  The amount of database wait time is basically identical to the elapsed time which means that you were only averaging one active session at a time.  If you believe that there are hundreds of users all waiting on the database at any point in time, this Statspack report would indicate that something else is the bottleneck.  If you believe there are only one or two users active at any point in time, this Statspack report would indicate that the database is probably the bottleneck.  If there were periods during the day where activity was particularly high, those spikes could be hidden by a Statspack report covering more than 5 hours.

Can you get the full text of the SQL statement and the plan for the this statement, which appears to be called from the procedure COM_MTIS.PRO_MIG_RTA_TRAFFIC_FLEET and accounts for 12% of your logical I/O

SELECT POL_POLICY_ID, POL_POLICY_TYPE, POL_CONC_POLICY_NO, NVL(P
OL_BR_CODE,POL_CUSTOMER_ID), CSH_E_NAME_1, VEH_START_DATE, VEH_E
ND_DATE, POL_ENDT_NO, VEH_ID, VEH_CHASSIS_NO, VEH_ENGINE_NO, VEH
_REGN_NO_TEXT, POL_ISSUE_DATE, POL_ISSUE_DATE, BR_E_NAME, '-', S
UBSTR(LOGIN_ID,1,12), POL_ENDT_ID, 'N', SUBSTR(PT_E_DESC,1,30),

Open in new window


and get the query plan for this statement which accounts for 9% of the logical I/O and was called 30,000 times?

SELECT COUNT(*) FROM TR_POLICY_RTA WHERE POL_NO= :B6 AND POL_CHA
SIS_NO = :B5 AND POL_MODEL_YEAR = :B4 AND POL_ISSUE_DATE = :B3 A
ND POL_START_DATE = :B2 AND POL_EXPIRY_DATE = :B1

Open in new window


My guess is that the latter is the search function your initial post was mentioning.
0
 
LVL 5

Assisted Solution

by:anand_20703
anand_20703 earned 250 total points
ID: 34276372
Hi,
Processer addition should not affect the performance. I doubt the SGA increase. As per your information, performance was ok before increasing the SGA to 1.8.
Just a quick check would to reduce the SGA to 1.2 back and check again. If this works, then increasing SGA could be causing more Paging to happen causing the slowness.
check it out.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Have you ever had to make fundamental changes to a table in Oracle, but haven't been able to get any downtime?  I'm talking things like: * Dropping columns * Shrinking allocated space * Removing chained blocks and restoring the PCTFREE * Re-or…
This post first appeared at Oracleinaction  (http://oracleinaction.com/undo-and-redo-in-oracle/)by Anju Garg (Myself). I  will demonstrate that undo for DML’s is stored both in undo tablespace and online redo logs. Then, we will analyze the reaso…
This video shows setup options and the basic steps and syntax for duplicating (cloning) a database from one instance to another. Examples are given for duplicating to the same machine and to different machines
This video explains what a user managed backup is and shows how to take one, providing a couple of simple example scripts.
Suggested Courses

622 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question