-none- 2004-06-17 - By -not available-
-- ---- ---- ---- ---- ---- -----
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
-- ---- ---- ---- ---- ---- -----
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
--0-1152524499-1087496870=:31427
Content-Type: text/html; charset=us-ascii
<DIV >Hi , </DIV >
<DIV > Thanks much for all the replies. I also thought the there some kind of delay/problem with app server and nothing to do with Database. But I couldn 't come to a conlusion as I am not able to fully understand the trace file. </DIV >
<DIV > </DIV >
<DIV >btw this trace file is genrated when handheld users synch their PDAs to Siebel application via landline phone connections. </DIV >
<DIV > </DIV >
<DIV >thanks again for all you time and taking a look into this. </DIV >
<DIV > </DIV >
<DIV >-Madhu <BR > <BR > <B > <I > "Daniel W. Fink " <optimaldba@(protected)> </I > </B > wrote: </DIV >
<BLOCKQUOTE class=replbq style= "PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid " >Madhu, <BR > <BR >Events associated with #0 are waits not associated with a cursor. I see these most often when an application has closed all the cursors, but is maintaining a connection. Oracle must associate these events with a cursor, but none are open, so it assigns them to #0. They are not assigned to a subsequent cursor as this cursor has not been opened when the event started. In this case, the XCTEND marks the end of a transaction. (I have not seen the second field as 'rd_onfiltered ' only as 'rd_only '). I can infer (please correct me if I am wrong) that the cursors associated with the transaction have all executed to completion (successful since rblk is 0, indicating the transaction was not rolled back) and the cursors are not active (but have not been closed since no STAT lines are output). Any subsequent events are associated with #0 (including the log file sync) u
ntil the
next cursor is opened or an existing cursor is reponed. <BR > <BR >The highlighted lines indicate that there is a period of 363.01 seconds where there was no interaction between the application and database. I would ask the app support team if this is normal. In the cases I have worked, this was a sign that an application server was maintaining a connection but not performing any database operations. Since this was expected and normal, I considered these events as truly idle. If the app team says that there should have been database access during that time, you can show that there was not and that the other tiers in the application architecture was consuming the response time. The bottom line in this event pair is that the database was not asked to do any work. <BR > <BR >In terms of #9, that cursor was opened sometime prior to #6. Since the first event associated with #9 in this example is an EXEC, we can infer that #9 has already been parsed (and perhaps even executed 1 or more
times). If you cannot find #9 in prior lines in the trace file, the tracing was started after #9 was parsed. If you are using MTS or connection pooling, this conclusion may be incorrect and I will defer to those with more experience tracing in that environment. <BR > <BR >Regards, <BR >Daniel Fink <BR > <BR >Madhu Konda wrote:
<BLOCKQUOTE cite=mid20040617124744.98445.qmail@(protected) type= "cite " >
<DIV >
<DIV >
<DIV >Hi All, </DIV >
<DIV > We are running Oralce 8.1.7. on HP-UX . Recently I traced a application (third party) and I see some the following information in the trace file . </DIV >
<DIV > </DIV >
<DIV >===================== <BR >PARSING IN CURSOR #6 len=181 dep=0 uid=8564 oct=6 lid=8564 tim=1314794115 hv=1049137217 ad= '712a38b0 ' <BR >UPDATE SIEBEL.S_EVT_ACT SET <BR > LAST_UPD_BY = :1, <BR > MODIFICATION_NUM = :2, <BR > APPT_START_DT = :3, <BR > LAST_UPD = :4 <BR > WHERE <BR > ROW_ID = :5 AND MODIFICATION_NUM = :6 <BR >END OF STMT <BR >PARSE #6:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=1314794115 <BR >EXEC #6:c=0,e=1,p=0,cr=4,cu=27,mis=0,r=1,dep=0,og=3,tim=1314794116 <BR >WAIT #6: nam= 'SQL*Net message to client ' ela= 0 p1=1413697536 p2=1 p3=0 <BR >WAIT #6: nam= 'SQL*Net message from client ' ela= 0 p1=1413697536 p2=1 p3=0 <BR >EXEC #9:c=0,e=0,p=0,cr=0,cu=4,mis=0,r=1,dep=0,og=3,tim=1314794116 <BR >WAIT #9: nam= 'SQL*Net message to client ' ela= 0 p1=1413697536 p2=1 p3=0 <BR >WAIT #9: nam= 'SQL*Net message from client ' ela= 1 p1=1413697536 p2=1
p3=0 <BR >XCTEND rlbk=0, rd_onfiltered=0 <BR >WAIT #0: nam= 'log file sync ' ela= 0 p1=170 p2=0 p3=0 <BR > <STRONG > <FONT style= "BACKGROUND-COLOR: rgb(255,0,0) " >WAIT #0: nam= 'SQL*Net message to client ' ela= 0 p1=1413697536 p2=1 p3=0 <BR >*** 2004-06-10 13:55:28.184 <BR >WAIT #0: nam= 'SQL*Net message from client ' ela= 36301 p1=1413697536 p2=1 p3=0 </FONT > </STRONG > <BR >===================== <BR > </DIV >
<DIV >From the trace output I can see that Parse#6,Fetch#6,WAIT#6 are attributed to Curosr #6 . But I am not able to figure out what event is invoking the WAIT#9 and WAIT # 0 . Also I am not able to figure out what event is causing this huge wait (363.01 secs) on SQL*Net message from client . </DIV >
<DIV > </DIV >
<DIV > </DIV >
<DIV >Can somebody please explain me whats going on here. </DIV >
<DIV > </DIV >
<DIV >TIA, </DIV >
<DIV >Madhu </DIV > </DIV > </DIV >
<P > </P >
<HR SIZE=1 >
Do you Yahoo!? <BR > <A href= "http://us.rd.yahoo.com/mail/taglines/*http://mobile.yahoo.com/maildemo " >Take Yahoo! Mail with you! </A > Get it on your mobile phone. </BLOCKQUOTE > </BLOCKQUOTE > <p >
<hr size=1 >Do you Yahoo!? <br >
<a href= "http://us.rd.yahoo.com/mail/taglines/*http://promotions.yahoo.com/new_mail/static/efficiency.html " >New and Improved Yahoo! Mail </a > - 100MB free storage!
--0-1152524499-1087496870=:31427--
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe send email to: oracle-l-request@(protected)
put 'unsubscribe ' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
|
|
