Re: ** trace file
- From: A Joshi <ajoshi977@xxxxxxxxx>
- To: ajoshi97@xxxxxxxxx, mathias.magnusson@xxxxxxxxx
- Date: Sun, 26 Apr 2009 08:54:52 -0700 (PDT)
Mathias,
Thanks for your help. Splitting the file after creating
the trace is not an option since I need to look at it for different
five minute intervals. I do need summary information on waits like i/o
wait for sequential read, scattered read so I know what is taking time.
binds I do not need. I mean this situation keeps coming up from
time to time for different reasons and I need to know what can be done.
In some cases : while the job is running a change like gather stats or
killing other processes which reduces load/eliminates locks might be
done and I need to see how much that improved if any. Yes, I can take a
tkprof before and then tkprof after and then calculate but separating
trace would be more helpful. Thanks
--- On Sat, 4/25/09, Mathias Magnusson <mathias.magnusson@xxxxxxxxx> wrote:
From: Mathias Magnusson <mathias.magnusson@xxxxxxxxx>
Subject: Re: ** trace file
To: ajoshi97@xxxxxxxxx
Cc: "oracle-l" <oracle-l@xxxxxxxxxxxxx>
Date: Saturday, April 25, 2009, 11:58 PM
Could
your problem be solved by creating smaller files after the trace has
finished? Or do you have to get smaller ones while running to manage
the diskspace?
If you did the echo, then what happened? Did the file not get any more data? If
not, did the inode change?
Do
you really need hours of trace information with all binds and waits? If
you are not investigating individual wait events, then you could of
course save a lot of space by not requsting the wait information.
Reading that much data from a raw
trace would seem more than daunting. But it ought to be technically
possible somehow. Woudl splitting after creating the trace file be an
option? If not, then looking into why you do not get more data after
truncating the file is what I think would be your next step.
One additional option could be to set client,
module, and action for different parts of your code to allow you to
trace just the statements you need information about.
Mathias
On Sun, Apr 26, 2009 at 5:24 AM, A Joshi <ajoshi977@xxxxxxxxx> wrote:
Mathias,
Thanks. I tried
> tracefile.trc
as 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
--- On Thu, 4/23/09, Mathias Magnusson <mathias.magnusson@xxxxxxxxx> wrote:
From: Mathias Magnusson <mathias.magnusson@xxxxxxxxx>
Subject: Re: ** trace file
To: ajoshi977@xxxxxxxxx
Cc: "oracle-l" <oracle-l@xxxxxxxxxxxxx>
Date: Thursday, April 23, 2009, 2:53 AM
It
sounds as if you may need to revisit your requirements. This would
create a file too large to work with. Has Oracle Support requested it?
Is the job not very repetitive so that any
five minutes will look virtually identical (assuming it is one single
batch process). If that would be the case, you would only need a trace
for a short period.
If yo need all of this trace data, then you could
copy from it to another file and then truncate it ( echo '' >
<file>). That resets the file pointer, while not changing the
inode for the file. While you're copying and truncating the file will
be written to so make sure you're not missing some data or getting half
written records, you will want to pause the process. In Solaris that
should be possible with the pstop command. It requires root or logging
in as the owner of the process.
Mathias
On Thu, Apr 23, 2009 at 3:30 AM, A Joshi <ajoshi977@xxxxxxxxx> wrote:
Thanks Tim,
Mathias,
Wolfgang,
tracefile_identifier does not seem to work for
:
oradebug setospid 400
oradebug unlimit
oradebug event 10046 trace name context forever , level 12
I have a job that goes 8 hours. It is same sid, spid, pid etc. and I
want a way to get a trace with different name. The trace file also
grows very fast.
Thanks
--- On Mon, 4/20/09, Tim Gorman <tim@xxxxxxxxx> wrote:
From: Tim Gorman <tim@xxxxxxxxx>
Subject: Re: ** trace file
To: mathias.magnusson@xxxxxxxxx
Cc: ajoshi977@xxxxxxxxx, "oracle-l" <oracle-l@xxxxxxxxxxxxx>
Date: Monday, April 20, 2009, 4:37 PM
Don't know if this helps, but be aware of ORADEBUG FLUSH and ORADEBUG
CLOSE_FILE as well. Might help with flushing remaining buffered output
to the trace file, then closing the file-descriptor to the file. Both
may help you move the file without weirdness due to open
file-descriptors....
Mathias Magnusson wrote:
How do you empty the file? If that would be a solution for you,
maybe the problem of not getting more data into it can be solved. It
sounds to me as if the filename you use exists on a different inode as
a result of the operation. Oracle would write to the inode it started
writing to no matter what you do to the file. So if you empty it and
the inode remains the same, I'd imagine new data would still show up in
the file.
Mathias
I also cannot remove the file or empty the
trace file. Because after that nothing goes into the file. Thanks
--
//www.freelists.org/webpage/oracle-l
Other related posts:
