Re: Another Oracle "Myth"?

Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1069538755.832436_at_yasure>...
> Michael J. Moore wrote:
>
> > Checking in late on this one but my reaction to what Mr. Millsap is saying
> > is basically "Well duh!"
> > It is like putting a program into a loop and watching the CPU race and
> > thinking that that means you have a very efficient program. It seems rather
> > obvious that hit ratio, as an isolated metric, is rather meaningless.
> >
> > Also, there is that old adage, "If it is too good to be true, it probably
> > is." Well, 99% is too good to be true so it is very suspicious and I think
> > Mr. Millsap is saying that the number one suspect would be a badly tuned SQL
> > statement.
> >
> > So, if the hit ratio is fairly low, and you know your SQL is well tuned,
> > then throwing more RAM at the problem is probably a good idea. Right?
> >
> > But this raises some questions in my mind that some of the gurus in here may
> > like to comment on.
> >
> > "When is a PHYSICAL IO NOT A Physical IO? and does it matter?"
> > I am thinking about RAM disk cache here, and RAID and any other type of
> > physical device that may look like a physical IO to Oracle but may not be
> > requiring an actual disk read. And then there is the problem of other
> > applications running on the same system that may be determining if Oracle's
> > request for a physical IO can be serviced by a Logical IO at the OS/device
> > level.
> >
> > Goodbye science, hello art.
> >
> > Mike
> >
> >
> ><snipped>
>
> Not claiming guru status but I'll give you my opinion:
>
> If it ain't broke don't fix it. By which I mean that there enough
> real problems in any database application that developers and DBAs
> should be focusing on those before worrying about hit ratios and
> whether an IO is or is not truly a physical IO.
>
> I've yet to see the database application where such esoteric issues
> where the root cause of the problem. Concentrate on the low hanging
> fruit ... indexes, bind variables, explain plan, autotrace, and hold
> code reviews and you'll likely never have to care.
>
> Which doesn't mean the topic isn't important but rather the point out
> that too often people get hung up on the esoteric and don't deal with
> the all too obvious.

The paper says explicitly, "Certainly, LIO processing is the dominant workload component in a competently managed system."

I'd say you should be considered a guru, since you've hit right on the weakness of the paper, and by extension a problem with a lot of the criticisms we have seen here in cdos - that is, most systems are not "competently managed," whatever that means. One needs to somehow get the system close to reasonable before one should worry about LIO's. Even before worrying about SQL tuning. Most of the criticism I've seen about the various tuning schemes seem to focus on particular issues, and even those are misrepresented as they are yanked out of context, while ignoring the reality of the zeitgeist.

jg

--
@home.com is bogus.
http://www.comics.com/comics/herman/archive/herman-20031120.html