| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Event 10046 trace
Hi ,
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.
btw this trace file is genrated when handheld users synch their PDAs to Siebel application via landline phone connections.
thanks again for all you time and taking a look into this.
-Madhu
"Daniel W. Fink" <optimaldba_at_yahoo.com> wrote: Madhu,
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) until the next cursor is opened or an existing cursor is reponed.
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.
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.
Regards,
Daniel Fink
Madhu Konda wrote: Hi All,
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 .
LAST_UPD_BY = :1,
MODIFICATION_NUM = :2,
APPT_START_DT = :3,
LAST_UPD = :4
WHERE
ROW_ID = :5 AND MODIFICATION_NUM = :6
END OF STMT
PARSE #6:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=1314794115 EXEC #6:c=0,e=1,p=0,cr=4,cu=27,mis=0,r=1,dep=0,og=3,tim=1314794116 WAIT #6: nam='SQL*Net message to client' ela= 0 p1=1413697536 p2=1 p3=0 WAIT #6: nam='SQL*Net message from client' ela= 0 p1=1413697536 p2=1 p3=0 EXEC #9:c=0,e=0,p=0,cr=0,cu=4,mis=0,r=1,dep=0,og=3,tim=1314794116WAIT #9: nam='SQL*Net message to client' ela= 0 p1=1413697536 p2=1 p3=0 WAIT #9: nam='SQL*Net message from client' ela= 1 p1=1413697536 p2=1 p3=0 XCTEND rlbk=0, rd_onfiltered=0
>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 .
Can somebody please explain me whats going on here.
TIA,
Madhu
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Thu Jun 17 2004 - 14:12:00 CDT
 |
 |