Re: ** trace file

> ... 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_at_gmail.com>
> wrote:
> From: Mathias Magnusson <mathias.magnusson_at_gmail.com>
> Subject: Re: ** trace file
> To: ajoshi97_at_yahoo.com
> Cc: "oracle-l" <oracle-l_at_freelists.org>
> 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.

--
http://www.freelists.org/webpage/oracle-l