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 PROTECTED]> wrote: > 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 instead of PARSE line. > > I'll take a stab at this ... lines with --> are > mine > > ===================== > PARSING IN CURSOR #1 len=94 dep=0 uid=83 oct=47 > lid=83 tim=1617285502494 hv=1138148843 ad='605d0998' > --> Anonymous block > BEGIN nav_tree_pkg.get_nav_parent_node_id( > :p_nodeid, :p_parentnodeid ); > END; > END OF STMT > --> anon block gets parsed, it probably contains a > sql. > PARSE > #1:c=0,e=141,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1617285502483 > --> Found the sql, so oracle opened another cursor > #1 which is dependent on cursor #1 so dep = 1 > PARSING IN CURSOR #2 len=68 dep=1 uid=98 oct=3 > lid=98 tim=1617285503241 hv=1778717541 ad='606795e8' > --> sql test > SELECT PARENT_NAV_NODE_ID FROM NAV_NODE WHERE > NAV_NODE_ID = :b1 > END OF STMT > --> Successful parsing of cursor #2 > PARSE > #2:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1617285503230 > --> Executing cursor #2 > EXEC > #2:c=0,e=151,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1617285503563 > --> Fetch cursor #2 > FETCH > #2:c=0,e=40,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=1617285503648 > --> Data returned to anon block > WAIT #1: nam='SQL*Net message to client' ela= 2 > p1=1413697536 p2=1 p3=0 > --> Now the anon block executes. the e time includes > the time for all actions of cursor #2 > EXEC > #1:c=0,e=1037,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=4,tim=1617285503786 > WAIT #1: nam='SQL*Net message from client' ela= 2470 > p1=1413697536 p2=1 p3=0 > > > Now, I'll just wait for Cary to come along and tell > me that I got it all wrong ... > > Happy Thanksgiving (or Turky Day) > Raj ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
