Re: ** trace file

  • From: A Joshi <ajoshi977@xxxxxxxxx>
  • To: breitliw@xxxxxxxxxxxxx
  • Date: Sun, 26 Apr 2009 09:00:27 -0700 (PDT)

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
 



      

Other related posts: