Thanks a lot, Cary.
Indeed the indented notation seems rather convenient.
I would be delighted to take your PD101 course, just
not sure if people here dealing with the training
budget would share the delight with me :-(
Doesn't hurt to ask though...
Thanks again,
Boris Dali.
__
Boris, thanks for sending me your data. The following note pertains only
to the excerpt you sent me; I didn't look at the whole trace file.
Here's the excerpt you sent:
=
PARSING IN CURSOR #1 len=94 dep=0 uid=83 oct=47 lid=83 tim=1614119418158
hv=1138148843 ad='605d0998'
BEGI
Thanks, Raj.
So yes, as I said in my other email - the rule stated
in the book seem to apply to EXEC db calls only (in
case of SQL fired from PL/SQL). I guess I
misinterpreted it the way that it applies to ALL db
calls for recursive cursors.
Thanks,
Boris Dali.
--- "Jamadagni, Rajendra"
<[EMAIL
But the previous email was a shining example of brevity in action! ;)
I'll have to wait for Cary, et.al. as well as my understanding is the exact same as
yours.
Daniel
"Jamadagni, Rajendra" wrote:
> Sorry about the last empty email ...
>
> Cary is right, the EXEC at dep=0 is the database call
Sorry about the last empty email ...
Cary is right, the EXEC at dep=0 is the database call you should be looking for, why?
because until #1 is parsed, db has no way of finding what needs to do. And once it
finds that "Oh I must run a SQL", the dep increases. So, I'd look for a subsequent
EXEC
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
-Original Message-
Sent: Monday, November 2
Thanks for your reply, Daniel.
Yes, it makes sense for the EXEC calls, but it doesn't
explain the PARSEs, does it?
PARSING IN CURSOR #1 len=94 dep=0...
PARSE #1:c=0,e=141,p=0,cr=0,cu=0,mis=0,r=0,dep=0...
PARSING IN CURSOR #2 len=68 dep=1...
PARSE #2:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=1...
Here
Boris,
Cary is correct. It gets a little confusing, especially with pl/sql
involved. It also helps to remember to differentiate between database
calls (parse/execute/fetch) and other events (wait/stat).
Using your example below, I'll attempt an explanation inline.
Daniel Fink
Boris Dali wrote:
Reading Cary's "Optimizing Oracle Performance", page
91 it says:
"A database call with dep=n+1 is the recursive child
of the first SUBSEQUENT (empasis mine) dep=n database
call listed in the SQL trace data stream"
Does this apply to the SQL issued from PL/SQL?
I am looking at the simple packaged
