Do you know Timmings for trace files generated?

Question

Hi,
I have done some sql traceing using DBMS_MONITOR package.
We can also enable SQL traceing using DBMS_SESSION.
I want to generate sql trace file for "particuler part of application".
When i did that i got some sql trace files,, now that "particuler part of application" was over application was idle..
but as time goes these files are still populating in size means they are still sql traceing going on...
My question is when and how trace files are generated?
Do you have idea???
Thanks and Regards,
Rushang Kansara
Message was edited by:
Rush

Answer 1

also what content of my sql trace file should i
consider for exacly tracing that "particuler part of
application".
Rushang
Parse Count To Execute Ratio
Take the numbers of parse count and divide it by numbers of time execute count if it is 1 then it means you are parsing the same statment everytime,If this ratio is 1 then it will latch the shared SQL area which will degrade the overall performance.Like if you execute a query which is using bind variable and this query is at yours front end level trigger (Forms) POST_QUERY then it will show you (parse count=execute count) which shows you are parsing for every triggering event which is bad ,for that you should put this seqeuel within PL/SQL procedure which cache the cursor and will turn in (parse count<Execute Count).
Large Diffrence Between Elasped Time And CPU Time
If this diffrence (Elapsed time[b]-CPU time)>1 then it means you are spending yours time in for waiting resources this waiting resources will in turn wait events e.g some one updated the row and dont realease by COMMIT or ROLBACK and the same span of time you want to update then you will see a lock in tkprof result in wait event section.If you read the data from hard disk (as first time you issue it reads from HD and then put into buffer cache during this reading a latch is grabed and will not let you read this data until you perform the alls read from HD to buffer cache this will also show you in wait events which is cache buffers chain
Fetch Calls
If yours Fetch calls=Rows then it means you are not using Bulk fetch and yours this code will take a lot of roundtrips which will in turn jam the network.
Disk Count
If every time yours disk count=current + query mode then you are reading alls block from disk alls the time ,usually oracle read once from disk and put it into SGA and should be found in SGA second time.
And there is many more...depend on yors environemnt setup but above are common.
As you said its reproducing the tkprof again and again ,make sure you terminate the session or you explicitly turn off the tracer by
ALTER SESSION SET SQL_TRACE=FALSE Khurram