Re: session time model issue

From: Tanel Poder <tanel_at_tanelpoder.com>
Date: Sat, 12 Jan 2013 21:57:54 +0200
Message-ID: <CAMHX9JKUOkSrUqAETnDVb4wVXqk8yhRYjk3ao9VggMgN+3WWUA_at_mail.gmail.com>

Just treat them as they are - if 1000ms out of a second is seemingly spent on execution and "additional" 900ms out of the same second were spent on hard parsing, then they both happened, but just at a different level or recursive depth.
I'm not saying that these operations were executing at the same time, but rather the parsing operation took a dive into (recursive) execution level and while recursive execution for the parsing operation was running, the time still was accounted for both (again it's just based on taking deltas between begin & end operation snapshots and recursive operations apparently break the logic somewhat).

I prefer this behavior to artificially hiding or subtracting time from raw measurements. Should it show 100% execution and 0% parsing - or only 10% on execution and 90% parsing in this case ... maybe a new time model metric "recursive execution time" could help ...

-- 
*Tanel Poder*
Online Training! - http://blog.tanelpoder.com/seminar
The Voicee App - http://voic.ee


On Thu, Jan 10, 2013 at 12:54 PM, Remigiusz Sokolowski <
remigiusz.sokolowski_at_nordea.com> wrote:



> Point taken - almost whole parse time elapsed is counted as hard parse

> and in trace file there is a lot of recursive queries as this is quite a

> complex query.

>

> So an additional question - how to treat these stats - because recursive

> sql is done on behalf of parsing actually?

>

> On 09.01.2013 17:51, Tanel Poder wrote:

> > Hi Remigiusz,

> >

> > This seems to happen (at least in some versions) when a (hard) parse

> > causes recursive SQL execution (for data dictionary access, FGAC

> > predicate generation etc) ...

> >

> > --

> > Tanel Poder

> > New Online Training! - http://blog.tanelpoder.com/seminar

> > The Voicee App - http://voic.ee

> >

> >

> > On Wed, Jan 9, 2013 at 3:09 PM, Remigiusz Sokolowski

> > <remigiusz.sokolowski_at_nordea.com

> > <mailto:remigiusz.sokolowski_at_nordea.com>> wrote:

> >

> >     On 09.01.2013 04:48, Jeremy Schneider wrote:

> >     > On Tue, 8 Jan 2013 12:49:44 +0100

> >     > Remigiusz Sokolowski <remigiusz.sokolowski_at_nordea.com

> >     <mailto:remigiusz.sokolowski_at_nordea.com>> wrote:

> >     >

> >     >> I have just reviewed the session time model gathered for a single

> >     >> query. My concern is that parse time elapsed is nearly 97% (and

> >     >> actually the whole amount is attributed to hard parse) of the DB

> time

> >     >> and sql execute elapsed time is 99% of the DB time.

> >     >>

> >     >> As this is for one session I assume there is no possibility the

> >     sum of

> >     >> ingredients is more than DB time (of course by much), so it seems

> >     >> reasonable to assume sql execute elapsed time is execute, fetch

> and

> >     >> parse, which is against the docs.

> >

>

>

> --

> Pole na kazi

>

> ----------------------------------------------------------------------

> Remigiusz Sokolowski <remigiusz.sokolowski_at_nordea.com>

> pos   : Senior DBA at DIiUSI

> addr  : Nordea Bank Polska SA, Luzycka 6A st, 81-537 Gdynia, Poland

> phone : +48 58 667 17 43

> mobile: +48 602 42 42 77

> Nordea Bank Polska S.A. z siedziba w Gdyni, ul. Kielecka 2, 81-303 Gdynia,

> wpisana do Rejestru Przedsiebiorców Krajowego Rejestru Sadowego pod

> numerem: 0000021828,

> dla której dokumentacje przechowuje Sad Rejonowy Gdansk - Pólnoc w Gdansku,

> VIII Wydzial Gospodarczy Krajowego Rejestru Sadowego,

> o kapitale zakladowym i wplaconym w wysokosci: 277.493.500,00 zlotych,

> NIP: 586-000-78-20, REGON: 190024711

>


--
http://www.freelists.org/webpage/oracle-l

Received on Sat Jan 12 2013 - 20:57:54 CET