Re: TKPROF Question

Init.ora parameter timed_statistics (sp?) must be set to true. Otherwise, the default 'false' value will cause sql trace to generate 0 values for CPU stats, as well as CPU stats in V$ views.

oops, I just noticed that you mentioned that you did make sure init.ora is set properly. If that is the case (did you restart the instance to make sure the init.ora changes take effect?), then the only other thing I can think of is that the lowest time granularity sql trace output is one hundredth of a second... if the instruction takes less than 1/100 a second (which means that the instruction has gotta be extremely simple - - select * from dual?). The 1/100 second granualrity is also the reason behind the anomaly that occasionally you'll see total CPU time is greater than elapsed time for some statements.

If you are daring, instead of looking at the tkprof output, you can look at the sql trace output directly. It takes a bit of educated guess to figure out what the data in tkprof means. I believe the value tracking CPU is 'hw=' ?

Pei
Oracle DBA

Darren Eccles <eg907259_at_stmail.staffs.ac.uk> wrote in article <3537C7B4.F98F0FA1_at_stmail.staffs.ac.uk>...
> I'm having trouble with getting timings for executed statements. If I
> issue a statement
> with the trace off and then issue it again with the trace on and then
> use TKPROF no
> timings are returned. Is this because no CPU time etc.. is required for
> statements that
> have already been issued before. Does Oracle store such info about
> previously executed statements so it can be used again if needed, to
> reduce load on the CPU? I'm a bit baffled. Are there any other
> explanations? I checked my init.ora settings and timing is set to true.
>
> Thanks in advance
>
>
Received on Sat Apr 18 1998 - 14:31:31 CDT