Notes in-line
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/seminar.html
Optimising Oracle Seminar - schedule updated May 1st
"Rick Denoire" <100.17706_at_germanynet.de> wrote in message
news:ggobd0507g1dmhrrn803amibl2aasa9bdm_at_4ax.com...
>
> And what if I got 4 CPUs (more complicated: 8 due to hyperthreading)?
> Should I then multiple the value times the number of CPUs?
No: any one Oracle process can use only one CPU. Even
if you execution parallel queries; the cost calculations in 9i works
on the basis of considering the fraction of the total job that a
single slave will execute - so needs the speed of a single CPU.
>
> > If you gather stats at an unlucky point in time, when
> > a rogue processing is causing bizarre tablescan response
> > then the MBRC and mreadtim values can be silly, and
> > it makes sense to adjust them
>
> I tend to believe that the gathering period should be long enough to
> be representative of most situations.
>
That's always the problem with using one number as a
system average - finding the 'most representative' number.
(That's partly why the buffer cache hit ratio was so easy
to abuse (in both senses of the word)).
> >
> > Depends how variable your workload is - for example:
> > A real, physical, tablescan may be the quickest way to get
> > the answer for (say) a 1 in 400 row query when no-one else
> > is using the system. If 25 other people are using the system
> > and doing the SAME thing, then they may all get the best
> > response time if they all did an indexed access path.
> > (Oracle is moving from Adam Smith to John Nash)
> > In general, though, I suspect that a neutral calibration of
> > i/o times, combined with a reasonable MBRC will be the
> > best for most systems.
>
> Sounds reasonable. I am biased because in our environment we have only
> a few users, and they put a heavy load on the DB due to DW type of
> operations.
>
Your bias is a valid observation based on your understanding
of the system. If the workload is always the same size, and always
the same type of task, then a single number representing the 'average
behaviour' will be pretty good for everyone.
Other people may think differently - but they probably have different
characteristic behaviour on their systems, and are therefore conditioned
differently about what constitutes 'normal' behaviour of Oracle.
Received on Wed Jun 23 2004 - 04:32:58 CDT
