Read the TKPROF

Question

Hi,
How to read the TKPROF file.I could n't able to understand that.
SQL ID : 1ykjp456y6f5b
SELECT a.CUSTOMERID, a.CUSTOMERNAME, a.ADDRESS1, a.CITY
FROM
CUSTOMERS a
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 66668 1.33 1.78 7002 73215 0 1000001
total 66670 1.33 1.78 7002 73215 0 1000001
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 103
Rows Row Source Operation
1000001 TABLE ACCESS FULL CUSTOMERS (cr=73215 pr=7002 pw=7002 time=16179 us cost=1926 size=55566441 card=882007)
I could able to understand the values.how the oracle calculating the values.

Answer 1

user3266490 wrote:
Hi,
thanks for reply.
I have the table customers which has 100000 rows and four columns;
I have to find the actual execution time for that table without executing query.
I tried to enable the trace and set autotrace traceonly statistics.
Is it correct method?When posting information, such as an explain plan, TKPROF output, or anything else where spaces are critical for understanding, please use a { code } tag (without spaces) before and after that section of your post.
Your two posts in this thread are a bit confusing. TKPROF reports are generated from 10046 trace files. 10046 trace files capture the actual execution statistics, which can only appear when the SQL statement actually executes. See this blog post for an example of what a raw 10046 trace looks like:
http://hoopercharles.wordpress.com/2009/12/01/10046-extended-sql-trace-interpretation/
The follow up post shows a TKPROF summary for a 10046 trace file, and describes the contents of the TKPROF output:
http://hoopercharles.wordpress.com/2010/01/26/10046-extended-sql-trace-interpretation-2/
SET AUTOTRACE TRACEONLY STATISTICSThe above command causes SQL*Plus to suppress the output of the rows from the query when it executes, and then print a summary of various statistics about the query execution.
Oracle is able to display estimated run time calculations, but the estimated time calculations are just that - the times may be significantly different than the actual execution times.
For anyone interested, here is a readable version of the TKPROF output that was provided by the OP:
SQL ID : 1ykjp456y6f5b
SELECT a.CUSTOMERID, a.CUSTOMERNAME, a.ADDRESS1, a.CITY
FROM
CUSTOMERS a
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch    66668      1.33       1.78       7002      73215          0     1000001
total    66670      1.33       1.78       7002      73215          0     1000001
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 103 
Rows     Row Source Operation
1000001  TABLE ACCESS FULL CUSTOMERS (cr=73215 pr=7002 pw=7002 time=16179 us cost=1926 size=55566441 card=882007)The above indicates that, from the database instance's perspective, the query required 1.78 seconds to execute. It may have required much longer than that for the rows to be retrieved by the client and displayed on the screen. If you captured a 10046 trace at level 8 the TKPROF output would also include wait event statistics. If you bump up the fetch array size from 15 to 100 or 1000, you might find that the query completes faster (there are a couple examples of this on my blog). You did not state the Oracle release you are using, but it appears to be 11.1.0.6 or higher.
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.