Wolfgang, Salute. I am using sunos version 10. Thanks a lot for demonstrating. I did do a oradebug event 10046 trace name context off in between so I do not know if that made a difference. At the next instance of this I will try the steps you listed and see. thanks --- On Sun, 4/26/09, Wolfgang Breitling <breitliw@xxxxxxxxxxxxx> wrote: From: Wolfgang Breitling <breitliw@xxxxxxxxxxxxx> Subject: Re: ** trace file To: ajoshi977@xxxxxxxxx Cc: "oracle-l" <oracle-l@xxxxxxxxxxxxx> Date: Sunday, April 26, 2009, 10:41 AM What OS are you using? This works just fine in Linux (and Oracle 10.2.0.3 - not that it matters) and ought to work just as well in any other unix. It may not work under windows where the trace file may be locked for writing by other processes. But then Windows is not a platform for production databases ( IMO - sorry, couldn't resist ). SQL> oradebug setospid 8298 Oracle pid: 15, Unix process pid: 8298, image: oracle@xxxxxxxxxxxxxxxxxxx SQL> oradebug unlimit Statement processed. SQL> oradebug event 10046 trace name context forever, level 12; Statement processed. SQL> oradebug tracefile_name /u01/oracle/admin/ora102/udump/ora102_ora_8298.trc in /u01/oracle/admin/ora102/udump/ I executed the following sequence of commands: cp ora102_ora_8298.trc ora102_ora_8298_001.trc cp /dev/null ora102_ora_8298.trc sleep 60 cp ora102_ora_8298.trc ora102_ora_8298_002.trc cp /dev/null ora102_ora_8298.trc sleep 60 cp ora102_ora_8298.trc ora102_ora_8298_003.trc cp /dev/null ora102_ora_8298.trc sleep 60 cp ora102_ora_8298.trc ora102_ora_8298_004.trc cp /dev/null ora102_ora_8298.trc sleep 60 cp ora102_ora_8298.trc ora102_ora_8298_005.trc cp /dev/null ora102_ora_8298.trc the result is $ ls -l ora102_ora_8298* -rw-r----- 1 oracle users 8166 Apr 26 08:25 ora102_ora_8298_001.trc -rw-r----- 1 oracle users 11325 Apr 26 08:26 ora102_ora_8298_002.trc -rw-r----- 1 oracle users 14456 Apr 26 08:27 ora102_ora_8298_003.trc -rw-r----- 1 oracle users 17611 Apr 26 08:28 ora102_ora_8298_004.trc -rw-r----- 1 oracle users 20470 Apr 26 08:29 ora102_ora_8298_005.trc -rw-r----- 1 oracle users 22747 Apr 26 08:29 ora102_ora_8298.trc Note that I did not close the trace file.Of course you will want to replace the fixed sleep intervals with variable time intervals depending on the application activity. It is important that max_trace_file_size is set to unlimited. Some OSs stop tracing when the size limit is reached, even if you switch to a new file with tracefile_identifier. And it may also be important not to close the trace file. At 09:24 PM 4/25/2009, A Joshi wrote: Mathias, Thanks. I tried > tracefile.trcas suggested by Franck Pachot. The file size comes down to 0. However, when I do : oradebug setospid 400 oradebug unlimit oradebug event 10046 trace name context forever , level 12 It does not write to the file at all. I do need this to work. We have lot of processes that run long. They do different processing : going to one table then to other and doing different sql, update and I would like to get the trace different. There are also some changes to the data and amount of processing so I need to do this from time to time. At one point I forgot to do oradebug event 10046 trace name context off after five minutes and it created a huge trace file and I could not work with it. It is difficult to upload big files to oracle support metalink. I have done compress or done ftp to oracle site sometimes. So it is different scenario but my requirement is same : I would like to have a different trace file or have a way to reduce the size of the trace file. Without running the risk of no trace being written to it. It is much worse if nothing gets written to it. Thanks Regards Wolfgang Breitling Centrex Consulting Corporation www.centrexcc.com