Re: buffer hit cache ratio

"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message news:<3ff14de6$0$13347$ed9e5944_at_reading.news.pipex.net>...
> "Joel Garry" <joel-garry_at_home.com> wrote in message
> news:91884734.0312291517.620af707_at_posting.google.com...
> > Isn't it a process of box ticking to _get_ you to the point of being
> > able to focus on response time? Surely you aren't advocating starting
> > with a default SGA on a new 6G system, when you have experience with a
> > smaller system running similar stuff. Don't you set parameters to
> > where you think they ought to be and then test? Even myths can be
> > useful ROT.
> >
>
> I agree that database creation and setup should *largely* be a process of
> box ticking. SGA sizing process considered, disk layout created and
> confirmed, naming conventions followed, init.ora considered and created, to
> that extent I *really* like the template feature that dbca provides. Its the
> idea that to *tune* a poorly performing system the best approach is to
> complete a checklist of database internals, rather than try and find what is
> causing which processes to perform inadequately that I don't like.
>
> You are correct about experience forming ones view. Mine is that once you
> have halfway sensible values for the buffer cache, shared pool etc. It is
> individual sessions that experience problems, not whole systems (though it
> can look like that if your monthly invoice production takes 52 hours to
> produce 700 invoices :( ).

Sounds like we're pretty much on the same page so far. That's why I think the books that are often ridiculed in this group are actually useful. In context, they can eventually get average DBA's to the point of being able to worry about things like LIO's and multiple hash join buffers.

jg

--
@home.com is bogus.
http://www.mandalavillage.org/zap_main.htm