Printable View
Why not tell Hit Ratio as CRAP :rolleyes: :rolleyes:Quote:
Originally posted by slimdave
just run some badly designed sql over and over again, thus increasing LIO's and herdly touching PIO's. That tells you all you need to know about how meaningful the ratio is.
Abhay.
But it's not! It's just one of many "tools" that you can use to judge if your db is healthy - you need to understand its usefulness and its limitations in the context of your db.Quote:
Originally posted by abhaysk
Why not tell Hit Ratio as CRAP :rolleyes: :rolleyes:
A generalisation and therefore false! HOWEVER in some proportion of cases, it might be a cost-effective solution: memory is cheap and consultants are expensive.Quote:
Originally posted by Alchemy
When I was being taught Oracle 9i(OCP) our Instructor made the point that if buffer cache hit ratio should be at the acceptable level of 95%, and if it fell below 95% to add more ram(tuning). All but 1 article that I have read on the subject, and outside books(2) that I have said the same thing, "when buffer cache hit ratio falls below 95% throw more ram(tuning) at it until it rises back up to 95%.
The proper solution is expensive because it requires someone to think about it:
a) Is there a problem?
A low hit ratio in itself is NOT a problem. (A few times per day, I have hit ratios around 20% for a few minutes when a user selects customers according to some ad-hoc profile. We made a conscious decision NOT to add a vast numbers of indexes to cover all eventualities, so most of these selections are FTS. Getting a customised client list in two minutes is very acceptable to the end-user - it would take 24hrs if he asked me to do it).
b) Why has the ratio changed?
c) Does it matter?
d) Should I fix it?
e) Can I fix it?
These may take weeks to answer. But these answers are the only valid ones.
Quote:
Originally posted by DaPi
But it's not! It's just one of many "tools" that you can use to judge if your db is healthy - you need to understand its usefulness and its limitations in the context of your db.
Ok, lets see how use full might be that * HIT Ratio *..
Case 1 :
Ratio > 95+
* Some argue that u gotta bad sqls where in ur LIOs shooting up so much that u cannot see the PIOs to be significant..
* But it can as well be some thing like ALL SQL perfectly tuned and ther isnt any crap requirement by which LIOs will have shoot up ... and yes now u can say HIT is perfect and u can be happy..
So with this u really cannot make anything unless u know what SQL are running and r they tuned and so many with respect to SQL.
Case 2 :
Ratio < 75-
* Some may argue that u have a balance between PIO/LIO and assume all SQL tuned one.
* Contradictory to it will be, there are very simple requirements (SQLs) and its codeded in such a fashion its worst ( BAD sqls ) and ofen reading data from files...
So with this as well u really cannot make anything unless u know what SQL are running and r they tuned and so many with respect to SQL.
So, why bother on HIT Ratio and just start looking for BAD SQLs and every one will be happy !
Abhay.
Ah, but WHEN do you look for BAD SQL? Possible answers:Quote:
Originally posted by abhaysk
So, why bother on HIT Ratio and just start looking for BAD SQLs and every one will be happy !
a) when someone complains
b) when the hit ratio changes unexpectedly
To my mind it's like a doctor using a thermometer: if the patient's temperature is normal, it doesn't necessarily mean he/she is in good health; if it is abnormal, better find out why.
On p11 of Millsap's article, he describes the hit ratio as "unreliable" - by his definition the doctor's thermometer is "unreliable" too. Would you expect doctors to stop using thermometers?
What would you think of a doctor who:
a) never used a thermometer?
b) never used anything but a thermometer?
Well the things (Ratio Vs Thermometer) u r trying relate will be meaningless...Quote:
Originally posted by DaPi
Ah, but WHEN do you look for BAD SQL? Possible answers:
a) when someone complains
b) when the hit ratio changes unexpectedly
To my mind it's like a doctor using a thermometer: if the patient's temperature is normal, it doesn't necessarily mean he/she is in good health; if it is abnormal, better find out why.
On p11 of Millsap's article, he describes the hit ratio as "unreliable" - by his definition the doctor's thermometer is "unreliable" too. Would you expect doctors to stop using thermometers?
Lets consider one by one cases..
1) Thermo shows too high value than the normal 98 F Vs Ratio Showing more than 98+
Conlusion from Thermo : Person is suerly not in good health.
Conclusion from Ration : Can u make?? ( coz it can be any may be good if all sqls running are good and no stupid requirements and also may not be good if bad sqls running )
2) Thermo shows normal value i.e 98 F Vs Ratio Showing 90 to 93.
Conlusion from Thermo : Person may or may not be in good health.
Conclusion from Ration : Can u make?? (here the ans being same).
3) Thermo shows too less value than the normal 98 F Vs Ratio Showing too less than 80 may be between (50 to 70)
Conlusion from Thermo : Person is suerly not in good health.
Conclusion from Ration : Can u make?? (here the ans being same).
Conclusion from above 3 : 2 out 3 cases for Thermo, u can be sure that something is wrong, but 0 out of 3 cases u are not sure that some thing is wrong/right ( Plainly by seeing Ratio ).
So can u realy corelate?
Yes ofcourse the second point u made ( drastic change in Hit Ratio is a very valid point, but with also u cannot be sure )..
as far as the quote
is concerned, both are CRAP !!Quote:
What would you think of a doctor who:
a) never used a thermometer?
b) never used anything but a thermometer?
I see u r big fan of * Hit Ratio * ;) ;)
Abhay.
Abhay, I think your comparison of hit ratio with temperature falls down because you know what is a "normal" temperature (actually my "normal" is 97.7 not 98.4 ! !) - for a db you need to find out what is "normal" for that db.
No not a big fan. Sometimes it's useful, so I don't call it crap.Quote:
I see u r big fan of * Hit Ratio *
Well David you are simply not willing to agree that Hit Ratio is meaningless...Quote:
Originally posted by DaPi
Abhay, I think your comparison of hit ratio with temperature falls down because you know what is a "normal" temperature (actually my "normal" is 97.7 not 98.4 ! !) - for a db you need to find out what is "normal" for that db.
Coz u know who u can decide a NORMAL temp for a person, u also know how to find normal Hit Ratio of DB ( and also know that large flucation of it is possible and not necessaryly a problem but that is not the case with thermo )...
:D :D
( i can say it be used very very rarely that to for an OLTP type system only & size of DB within TB & no no for DW/DSS )
Can someone please tell me why BAD SQL (poorly tuned) causes more LIO than PIO?
I always thought that whether or not a query used the Buffer Cache or Disk depended on whether or not the blocks were in memory. So why would a poorly written statement do this more than a well tuned one? Surely its a matter of the blocks ageing out of the buffers ...?
I (obviously) have little experience in this aspect of the job. In 4 years we've never had a user complain about poor performance so I've had little scope to justify (to management) any time spent tuning the DB. So - I'm trying to learn it theoretically and came upon some contradictory 'advice' (my original post).
The amount of LIO's practically defines what is good and what is bad SQL (relatively).Quote:
Originally posted by JMac
[B]Can someone please tell me why BAD SQL (poorly tuned) causes more LIO than PIO?
Try the following ...
Try these on your system ... same result, different LIO's.Code:set autotrace on
select owner,object_name from dba_objects
where timestamp =
(select max(timestamp) from dba_objects)
/
select owner,object_name
from
(
select owner,object_name,timestamp,
max(timestamp) over () max_timestamp
from dba_objects
)
where timestamp=max_timestamp
/
Now if this were a user query then the blocks would either be in memory or not, so the PIO's would be the same. On my little test system I got 41420 consistent gets for the first methodology and 20710 for the second -- exactly half. The cache hit ratio for second methodology is therefore half of the ratio for the first methodology.
You see? Better SQL = lower cache hit ratio. High cache hit ratio = potentially bad SQL.