Re: buffer hit cache ratio should be ...

"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. Received on Mon Dec 29 2003 - 09:50:40 CST