Re: ** trace file
- From: Martin Berger <martin.a.berger@xxxxxxxxx>
- To: ajoshi977@xxxxxxxxx
- Date: Sun, 26 Apr 2009 19:54:18 +0200
... 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'm not really sure what you really need. (I followed the thread, but
did not make my mind yet).
Maybe either AWR (if you are on version 10+ and are licensed) and/or
sampling v$sesstat might bring enough informations without activating
the tracing-code at all?
just an idea, probably an unusable.
Martin
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.
Other related posts:
