Cary,
I'd like to place my pre-order on that book right now please.
Rachel
--- Cary Millsap <[EMAIL PROTECTED]> wrote:
> Dan,
>
> I think I can convince you of the contrary, but I doubt that I can do
> it
> solely via email. In our Clinics, where we spend three solid days
> addressing of all of the reservations you've stated below (including
> proof with examples of why "holistic" approaches are unreliable, and
> why
> we believe response time analysis is actually the fastest route to
> root-cause identification). The goal of the Clinic is to send you
> home
> able to actually *do* the stuff you see us writing about...
>
> One of the reasons I'm so confident in Response Time analysis is that
> it
> seems to be the final convergence for performance optimization work
> in
> other industries, some of which have been evolving for over a
> century.
> For a really nice description of one such industry, read Eli
> Goldratt's
> "The Goal."
>
> What Response Time analysis gives you that ratios don't is a valid
> priority-based task order. To take your cue, you're right: a slow
> response time on a query *could* indicate any of literally hundreds
> of
> different root causes. But seeing a Response Time account of exactly
> what that query did will show you exactly where that query spent its
> time. Consequently, you'll see exactly what you need to repair.
> However,
> if you're not looking at those response time statistics, then the
> only
> method you're left with is to check each of the hundreds of things
> that
> *might* have caused the query to be slow. Ratios are supposed to
> guide
> you through that process, but they often mislead you (as Dave Ensor,
> Graham Wood, Anjo Kolk, Jonathan Lewis, Connor McDonald, Steve Adams,
> Gaja Vaidyanatha, Kirti Deshpande, John Kanagaraj, James Morle,
> Mogens
> Nørgaard, Jeff Holt, I, and several others keep demonstrating).
>
> We visit several sites each year who have suffered the same
> performance
> problem for months or years. They've checked everything they can
> think
> of, and they haven't found the problem root cause. It is extremely
> rare
> for the same people to require more than one hour to positively
> identify
> and begin the repair of the correct root cause, when presented with
> Response Time data. It's mind boggling how difficult it is to
> convince
> people to do it that way for the first time. Once they try it, they
> never go back.
>
> * * *
>
> Within the next few months, I hope to have completed my book project
> ("Oracle Response Time Optimization" or some-such). The questions on
> this list are exceptionally good inspiration for such a project, by
> the
> way. When the book is finished, if I still haven't convinced you,
> then I
> simply won't have done my job.
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
>
> Upcoming events:
> - Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11
> Honolulu
> - 2003 Hotsos Symposium on Oracle® System Performance, Feb 9-12
> Dallas
> - Next event: NCOAUG Training Day, Aug 16 Chicago
>
>
>
> -----Original Message-----
> Sent: Friday, August 09, 2002 12:09 PM
> To: Multiple recipients of list ORACLE-L
>
> <Putting on t-shirt with honkin' big red bullseye target on the front
> and
> back>
>
> Stream of conciousness/random thoughts...
>
> To focus exclusively on response time is to fall victim to the same
> fallacy
> as focusing exclusively on hit ratios. The fallacy is that there is
> one
> and
> only one methodology to use for tuning/troubleshooting. In 5 years,
> another
> approach will supplant response time tuning and we will all scratch
> our
> heads and wonder why Anjo and Cary could not see the obvious. Just
> kidding...you guys will probably be the first to say "While the other
> approach was good, here is why the new approach is better with this
> new
> technology/knowledge".
>
> The best approach, which is often preached, is to use the holistic
> approach.
> I recall a paper from some years ago that discussed this approach.
> Most
> of
> the
> tuning books advocate such an approach, but we techies get bogged
> down
> in
> the day to day operations and only read the chapters that are of
> immediate
> concern.
>
> A poor hit ratio (of any cache) may indicate a problem, even if the
> response
> time is adequate. How many systems never increase in size or number
> of
> users?
>
> Response time monitoring describes the symptom. It does not define
> the
> root
> cause. A large number of waits for the database writer does not
> conclusively
> determine a single root cause. Rather, there are many possible causes
> (from
> the cache to processes to i/o subsystem). A slow response time on a
> query
> could indicate a malformed query, missing/present indexes, poor
> storage
> parameters, an invalid high water mark, excessive read consistent
> transforms, i/o contention, etc.
>
> One reason why hit ratios are nice is that they are tangible and
> measurable.
> Response time satisfaction is not. What is 'slow' to one user is
> 'fast'
> to
> another.
>
> Thoughts...<ducking the inevitable flaming emails>
>
> Dan Fink
>
> -----Original Message-----
> Sent: Friday, August 09, 2002 4:18 AM
> To: Multiple recipients of list ORACLE-L
>
>
> Cary,
>
> I love to talk about the response time thing, but it shouldn't be a
> lunch but a big dinner (will also settle for Tuborg and hotdogs ;-)).
>
>
> I think it is acutally great to see this discussion on the BCHR. I
> don't
>
> except people to jump to response time tuning directly and drop the
> ratio tuning thing. However the response time tuning approach works
> great also for management. They like to hear things like 85 percent
> of
> the end user response time is in the network, because the hit ratio
> could be perfect in this example (but the problem is outside the
> database and the hit ratio will not show that .......).
>
> Reponse time/Throughput tuning is not perfect yet. There are may be 1
> or
>
> 2 tools that look at the whole stack and correlate that information.
> There are no large number of tuning books about it, so people end up
> buying the wellknown BCH books. Eventually the whole thing will
> change.
> Even Oracle changed STATSPACK in 9.2 to include the CPU time in the
> TOP5
>
> wait events (now why did they do that ;-))
>
> I have to mow the lawn, the wife complains about the response time
> (it
> takes weeks to get a reply from me ;-). Will hear from you guys
> later, I
>
> am sure ......
>
> Anjo.
>
>
> Cary Millsap wrote:
>
> >Sure, I'd love to comment...
> >
> >1. If you can inexpensively cache your whole database working set in
> >memory, there's nothing wrong with doing that *unless* you could
> have
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Rachel Carmichael
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
