Re: buffer hit cache ratio should be ...

From: Frank van Bortel <fvanbortel_at_netscape.net>
Date: Mon, 29 Dec 2003 21:30:19 +0100
Message-ID: <bsq2b9$g03$1@news4.tilbu1.nb.home.nl>

Ryan Gaffuri wrote:

> "Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message news:<3ff0044c$0$13355$ed9e5944_at_reading.news.pipex.net>...
>

>>"Ibrahim DOGAN" <idogan_tech_at_yahoo.com> wrote in message
>>news:6bf58828.0312240545.7865dd29_at_posting.google.com...
>>
>>>Frank van Bortel <fbortel_at_nescape.net> wrote in message news:<bsae44$8t5
>>>
>>>>In other words: don't bother. I'd worry if users start complaining,
>>>>and run then statspack - or HotSos's tools.
>>>>
>>>
>>>that's so bad if you find out the issues about your databases when
>>>users start complaining about them.. Look up the term "proactive DBA"
>>>in your DBA dictionary...
>>>
>>>DBAs should promote continous monitoring to fix the problems before
>>>they surface to user community instead of sitting back, waiting the
>>>time users start screaming around about the performance...
>>
>>
>>Fine. But what do we monitor? I'd suggest that the only things that really
>>count are
>>
>>1. Response time of key business processes.
>>2. Throughput for key business processes.
>>
>>The problem with monitoring changes in ratios is that it doesn't really tell
>>you anything useful about the end-user experience. It might alert you to the
>>fact that *something* has happened, but it will likely not tell you what. Of
>>course identifying what the key business processes are and how long they
>>take and what their volume is is much more difficult than calculating stats
>>for a dashboard.

>
>
> I think response time can be misleading. When you are tuning batch
> processes or large sql statements then its important.
>
> however, if your tuning for throughput, when you try to 'improve' a
> query, you should look to lower logical I/Os, then stress test it for
> response time improvements.
>
> Ive found that I can lower my logical I/Os by 50% or more when the
> query is run independently with little or no response time
> improvements, then when I stress test it, the response time difference
> is quite large.
>
> So it depends what your system is doing. will you have alot of users
> and/or have the query run alot? look for logical I/Os.
>
> if its a batch process, where it run once and not alot of stuff is
> running with it, then look for response time. Ive gotten large
> response time improvements with 'fast full index scans' that coincide
> with 30% or greater increases in logical I/Os, but since its a batch
> and Im not competing for resources, I dont care about the logical
> I/Os. I just want it to finish faster.

Last line... "finish faster" - isn't that response time ?!? :-0

I agree on the stress test stuff, if you add (or can read asif) scalability

-- 
A prosperous 2004,
Regards,
Frank van Bortel

Received on Mon Dec 29 2003 - 14:30:19 CST