--
"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message
news:3efbfc40$0$19598$ed9e5944_at_reading.news.pipex.net...
> "Burton Peltier" <burttemp1REMOVE_THIS_at_bellsouth.net> wrote in message
> news:mGSKa.19655$XR4.905_at_fe03.atl2.webusenet.com...
> > --
> > "Jim Kennedy" <kennedy-down_with_spammers_at_attbi.com> wrote in message
> > news:WTDKa.25341$e26.17141_at_rwcrnsc52.ops.asp.att.net...
> > > I agree with Niall. Often high CPU usage is an indication of lack of
> bind
> > > variables in an application.
> >
> > Really? There are soooo many other things I'd consider before looking
at
> > "lack of bind variables" .
> >
> > A quick/brief list that come to mind, at this time:
> > - Not tuned Sql
> > - Not tuned Sql
> > - Not tuned Sql
> > - etc. etc. etc.
>
> Hi Burton
>
> If I might be so bold I think you might be missing 'Not tuned Sql' from
your
> list :( Jim does have a very valid point though, since not using bind
> variables will cause each statement to be parsed - instead of parse once
> execute many. What resources does excessive parsing use? CPU.
>
I was just having fun and a little too late at night I suppose.
Anyway, of course, looking to see if not using bind variables is part of
tuning Sql.
But, having a system with the CPUs busy could be ok IF everyone's response
time is good and everything is tuned.
Whenever our server's CPUs get "busier than usual" (requires some idea of
what is "normal"), I take a look and almost always find some SQL that is not
tuned that someone put into production. Obviously, we could use some better
change control processes.
> What I didn't mention which might have been more helpful than just saying
> that oracle will use all available processors is that statspack will tell
> you what resources you are using, so I'd say setup statspack and measure
> your instance to see what is going on.
>
>
> --
> Niall Litchfield
> Oracle DBA
> Audit Commission UK
>
>
Received on Fri Jun 27 2003 - 16:52:38 CDT
