Re: SQL TRACE output contents

Lee E Parsons <lparsons_at_world.std.com> wrote:
>Gary Nystrom <gnystrom_at_umich.edu> wrote:
>
>>PARSING IN CURSOR #1 len=829 dep=1 uid=26.
>>
>>The dep field also appears in lines starting with PARSE #n, EXEC #n, and
>>FETCH #n. I kind of figure uid is the user ID number. Can anyone shed
>>any light on dep and len, and perhaps also share tips on intrepreting the
>>SQL_Trace output. It doesn't appear these two are addressed in TKPROF output.
>
>len is the length of the sql statement that follows. it tells tkprof how
>many characters to read when it is parsing the file. (this incidently
>is how I get around the 7.0 tkprof bug associated with ORA-00933. If you
>have gotten it you know what I'm talking about.)
>
>I think dep = depth and is a statement to prof about the statements level
>of recursion. This is ofcourse a wild ass guess but my spot check seems
>to support the theory.
>
>Frankely I can't make heads or tails out of the raw tracefile. My only
>interest in changing it has been to break it and watch tkprof do weird things.
>God, what a boring life. :-}

Lee is correct. The output from SQL_Trace is not meant to be human readable. It is meant to be fed to the TKPROF utility which makes use of all those blort=12345 entries in the file. TKPROF is documented in the Oracle 7 Application Developer's Guide manual. The format of the SQL_Trace output is subject to change at anytime as we continually try to refine the data collected and how TKPROF massages it. This is also documented in the aforementioned manual.

I think backports to 7.0.16 _may_ be available on some ports for the bug Lee mentioned above (bug# 169181) but I am not certain.

doug rady
drady_at_us.oracle.com Received on Fri Aug 12 1994 - 08:52:35 CEST