Re: 10046 trace question + ORASRP possible problem.
- From: "Alex Gorbachev" <gorbyx@xxxxxxxxx>
- To: norman.dunbar@xxxxxxxxxxxxxxxxxxxxxxxxx
- Date: Sun, 2 Jul 2006 20:56:45 +0200
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@xxxxxxxxxxxxxxxxxxxxxxxxx>:
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
