Re: 10046 trace question + ORASRP possible problem.

I guess you are correct and latch free waits should be attributed to PARSE call (LC latch contention is quite appropriate for parsing and 220 ms of CPU suggest that you are probably spinning hard on latches).

Also, STAT #1 line means that your first cursor is closed at the time WAIT #1 lines are dumped to the trace file.

If I remember correctly, the only time I saw waits should be attributed to previous call is with "log file sync" that is dumped after commit line XCTEND, which is not really a call. Also one can question if the immediate "SQL*Net message to client" sometimes should be attributed to previous call.

2006/6/30, Norman Dunbar <norman.dunbar_at_environment-agency.gov.uk>:
> STAT #1 id=1 cnt=4 pid=0 pos=1 obj=1660748 op='TABLE ACCESS FULL
> A_TABLE_NAME '
> WAIT #1: nam='latch free' ela= 100 p1=-4611686017037494072 p2=555 p3=0
> WAIT #1: nam='latch free' ela= 47 p1=-4611686017037492344 p2=555 p3=0
> WAIT #1: nam='latch free' ela= 179 p1=-4611686017037492344 p2=555 p3=0
> WAIT #1: nam='latch free' ela= 107 p1=-4611686017037492344 p2=555 p3=1
> WAIT #1: nam='latch free' ela= 3 p1=-4611686017037493208 p2=555 p3=0
> WAIT #1: nam='latch free' ela= 11 p1=-4611686017037492632 p2=555 p3=0
> WAIT #1: nam='latch free' ela= 205 p1=-4611686017037492632 p2=555 p3=1
> WAIT #1: nam='latch free' ela= 94 p1=-4611686017037492632 p2=555 p3=0
> WAIT #1: nam='latch free' ela= 108 p1=-4611686017037493496 p2=555 p3=0
> WAIT #1: nam='latch free' ela= 135 p1=-4611686017037492344 p2=555 p3=0
> =====================
> PARSING IN CURSOR #1 len=199 dep=0 ...hv=2
> SELECT more_stuff FROM another_table WHERE column = :bind_var
> END OF STMT
> PARSE
> #1:c=220000,e=222788,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=0,tim=3355551716148

-- 
Best regards,
Alex Gorbachev

http://blog.oracloid.com
--
http://www.freelists.org/webpage/oracle-l