Re: What do you make of this?
- From: Paul Baumgartel <paul.baumgartel@xxxxxxxxx>
- To: niall.litchfield@xxxxxxxxx
- Date: Mon, 12 Sep 2005 10:35:08 -0400
Niall,
It is a COM+ client app, and there certainly are double parses. The puzzle
is that I'm used to this behavior (I have done many traces on this app,
although this one involved a newly-added feature), and don't usually see the
discrepancy between CPU and elapsed that I see here. But it's worth a try to
eliminate the double parses. Thanks for your help
Paul
On 9/12/05, Niall Litchfield < niall.litchfield@xxxxxxxxx> wrote:
>
> I'd guess that there's an ODBC connection in there right? I too have seen
> the parse twice execute once behaviour with this (and that'll be your
> biggest single winner. I *think* that one gets this behaviour with the ODBC
> call SQL_DESCRIBE_COLUMNS (or similar name), but as the app that does this
> to us is shrink-wrapped I haven't confirmed - though I did pass it back to
> the vendor.
>
> On 9/9/05, Paul Baumgartel < paul.baumgartel@xxxxxxxxx> wrote:
> >
> > Hi, all. Oracle10g (10.1.0.4.0) on Windows 2000.
> >
> > I have a set of traces that are puzzling. I had the traces done in
> > controlled conditions, with a single user on the database; CPU usage on the
> > DB server was less than 25%. This statement is a good example of what I'm
> > trying to figure out. There's a high ratio of elapsed to CPU on the parse,
> > but not much in the way of wait information--except the SQL*Net message
> > from
> > client. The client is a COM+ application server. No recent changes that I
> > know of on that machine, nor on the DB server itself. I have inspected the
> > raw trace file as well and don't see anything to suggest that the tkprof
> > timing summaries are incorrect.
> >
> > II'm looking for ideas on how to go about diagnosing the SQL*Net waits
> > (assuming they're accounting for the different between CPU and elapsed) or
> > finding where the rest of the elapsed time comes from. Thanks in advance
> > for
> > any suggestions!
> >
> > UPDATE VALIDKEYS SET LASTACCESS = :V00001
> > WHERE
> > VALIDKEYS_PK = :V00002
> >
> >
> > call count cpu elapsed disk query current rows
> > ------- ------ -------- ---------- ---------- ---------- ----------
> > ----------
> > Parse 198 0.46 2.72 0 0 0 0
> > Execute 99 0.12 0.49 0 297 396 99
> > Fetch 0 0.00 0.00 0 0 0 0
> > ------- ------ -------- ---------- ---------- ---------- ----------
> > ----------
> > total 297 0.59 3.22 0 297 396 99
> >
> > Misses in library cache during parse: 0
> > Optimizer mode: ALL_ROWS
> > Parsing user id: 12492
> >
> > Elapsed times include waiting on following events:
> > Event waited on Times Max. Wait Total Waited
> > ---------------------------------------- Waited ---------- ------------
> > SQL*Net message to client 381 0.00 0.00
> > SQL*Net message from client 381 0.01 0.51
> > log file sync 1 0.00 0.00
> >
> > ********************************************************************************
> >
> > --
> > Paul Baumgartel
> > paul.baumgartel@xxxxxxxxxxxx
> >
> >
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.niall.litchfield.dial.pipex.com
--
Paul Baumgartel
paul.baumgartel@xxxxxxxxxxxx
Other related posts:
