Re: Database Hit Ratios

John,

I managed to get a paper of mine in for OW Copenhagen, with the title:

THE DATABASE GETS BETTER, BUT THE METRICS LOOK WORSE. which contains the paragraph:

    The ideal was to get a figure close to 100, and the purpose of the     calculation was simply to answer the question - do I really need     to buy more memory? However, a frequently overlooked detail of     the formula was that it assumed that the database was behaving     as efficiently as possible so that the effects of extra memory would     simply allow the same amount of 'logical' work to be done with fewer     accesses to disk.

Of course, this was in the days of Oracle 5.1 when memory was very expensive, and designers/developers/coders still worried about efficiency at an early stage in development.

Richard is absolutely correct - interpretation, and understanding, are crucial. The vicious condemnation, and satirical mocking, of the buffer cache hit ratio, in particular, is the result of an urge to shock people into thinking. Perhaps it makes it too easy for people to believe that "hit ratios are bad", rather than "hit ratios are secondary".

--
Jonathan Lewis
http://www.jlcomp.demon.co.uk

Next Seminars
        UK            July / Sept
        Australia      July / August
        Malaysia        September
        USA (MI)        November
http://www.jlcomp.demon.co.uk/seminar.html

John Beresniewicz wrote in message ...


>Richard -

>

>Nice job putting the hit ratio "controversy" into a more reasonable frame

of


>reference.  Your suggestion hit ratios make sense under the assumption of

>prior minimization of logical I/O's is a good one, but therein also lies

the


>"tough nut" to crack.  A well-designed system focusing on mimizing logical

>I/O for the work to be done is one that has been tuned by design and this

is


>of course the best and most cost-effective time for performance tuning.

>