http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/sqltrace.

htm--
sqltrace and tkprof

http://www.oracleutilities.com/OSUtil/tkprof.html--tkprof

TKPROF
A utility that translates the SQL_TRACE file into readable output and can also show the
execution plan for a SQL statement

TKPROF: Interpreting the Trace File

The TKPROF utility translates a trace file to a readable format. You can run TKPROF
against a trace file that you have previously created using SQL_TRACE or ORADBX, or
you can run it while the program that is creating the trace file is still running. You can
optionally tell TKPROF to invoke the EXPLAIN PLAN statement (described in the next
section) for the statements being analyzed.
You invoke TKPROF by issuing the command
TKPROF tracefile listfile [SORT = parameters] [PRINT = number]
[INSERT = FILENAME] [SYS = YES/NO] [TABLE = schema.table]
[EXPLAIN = username/password] [RECORD = filename]
where
tracefile
Is the name of the trace file containing the statistics gathered by the trace facility. The
trace file is stored in the directory specified by the INIT.ORA parameter
USER_DUMP_DEST
listfile
Is the name of the file where TKPROF writes its output.
SORT=parameters
Is the order in which to display output. You can specify, as parameters, any of the
statistics collected by SQL_TRACE. (These are listed in Table 10-3.) TKPROF outputs
statistics in the descending order of the values of these parameters. For example, if you
specify
SORT = EXECPU
TKPROF first displays statistics for the statements that had the worst EXECPU values
(that is, required the most CPU time).
If you specify more than one parameter, for example, SORT = (FCHPHR, PRSCPU)
TKPROF adds the statistics you specify. The output that appears first is for statements in
which the sum of these two statistics was the worst.
PRINT = number
Is the number of statements included in the output. You might want to limit the amount
of output to the worst-performing statements.
INSERT = filename
Creates a SQL script that can be used to store the trace file statistics in the database. The
script name is identified by filename.
SYS = yes/no
Allows you to include Oracle's own dictionary statements. Including these statements
makes your output considerably longer. It is usually best to set SYS=NO.
TABLE = schema.table
If many users are using TKPROF at the same time, you may get situations in which the
users are interfering with each other's output. This is because TKPROF uses a single table
in the database to store its EXPLAIN PLAN details. The table is called
PROF$PLAN_TABLE. If the table doesn't exist, TKPROF creates it for you, uses the
table, and then drops it. If the table does exist, TKPROF removes the rows from the table,
which can create problems if there are multiple users. This option allows you to specify
another table name, for example, MARKG_PLAN, to avoid conflicts.
RECORD = filename
Allows you to store a SQL script from your trace file so that you can replay your
commands and test the effect of changing indexes and changing the optimizer. The
recursive calls are removed from the script automatically.
EXPLAIN = username/password
Runs the EXPLAIN PLAN statement on all of the statements in the trace file, logging in
under the account specified.
For example, you might specify
TKPROF 12_12626.TRC TRACE.LIS SORT=(EXECPU) EXPLAIN =
username/password SYS=NO
When you run TKPROF, it interprets the trace file and puts the readable output in the file
you specify. TKPROF produces a formatted listing. The rows and columns in the
TKPROF output have the meanings shown in Table 10-2.
Table 10-2:
Row/Column Description
Statistics for the parse steps performed by SQL statements. Parsing checks for
Parse security, and the existence of tables, columns, and other objects being referenced by
your SQL.
Statistics for the execute steps performed by SQL statements. UPDATE, DELETE,
Execute and INSERT statements show the number of rows processed here. SELECT
statements list the number of selected rows.
Statistics for the fetch steps performed by SQL statements. SELECT statements
Fetch show the number of rows processed here. UPDATE, INSERT, and DELETE do not
return rows for this value.
Number of times a SQL statement is parsed or executed, plus the number of times a
count
fetch is performed in order to carry out the operation.
cpu CPU time for all parses, executes, and fetches in seconds.
elapsed Elapsed time for parses, executes, and fetches in seconds.
Number of data blocks read from disk for each parse, fetch, or execute. If a single
multiblock read returns eight blocks, this figure is incremented only once for the
disk
physical read. Most disks operate at 50+ I/Os per second, so if you divide the figure
by 50, you can usually get a good idea of the time taken to perform the disk reads.
Number of times a buffer was returned in consistent mode, that is, the data is for
query
query only and has not been modified since the SELECT statement started.
current Number of times a buffer was retrieved for INSERT, UPDATE, or DELETE.
Number of rows processed by a SQL statement (only queries, not subqueries).
Unfortunately, this figure does not include the rows returned by subqueries. The
rows
number of rows returned appears in the fetch step for the SELECT statement and in
the execute step for the INSERT, UPDATE, and DELETE statements.
Following is an example of TKPROF output illustrating the rows and columns shown in
Table 10-2. Notice that the cpu and elapsed times are 0.00. This is because the INIT.ORA
parameter TIMED_STATISTICS is set to FALSE. If you set it to TRUE, you get more
information, but it does have a 5% to 10% performance drag on your machine.
SELECT D.dept_name, E.surname
FROM emp e , dept D
WHERE D.dept_no like `ACC%'
AND D.dept_no = E.dept_no
ORDER BY D.dept_name, E.surname;
count cpu elapsed disk query current rows
Parse: 1 0.00 0.00 3 11 0 0
Execute: 1 0.00 0.00 0 0 0 0
Fetch: 1 0.00 0.00 9 29 4 90

Misses in library cache during parse: 1

 Parsing user id: 8
Rows Execution Plan
--------- ------------------------------------------------------------
90 MERGE JOIN
4 SORT JOIN
4 TABLE ACCESS BY ROWID DEPT
4 INDEX RANGE SCAN DEPY_IDX2
86 SORT JOIN
86 TABLE ACCESS BY ROWID EMP
86 INDEX RANGE SCAN EMP_IDX2
You can select any of the statistics shown in Table 10-3, computed by SQL_TRACE and
interpreted by TKPROF, in the SORT clause. Of these, EXECPU (if you have set
TIMED_STATISTICS=TRUE), PRSDSK, FCHDSK, and EXEDSK are probably the
most useful. EXECPU shows the total CPU time spent executing the statement; and
PRSDSK, FCHDSK, and EXEDSK record the number of disk reads.
Table 10-3:
Parameter Description
PRSCNT Number of times parsed
PRSCPU CPU time spent parsing
PRSELA Elapsed time spent parsing
PRSDSK Number of physical disk reads during parse
PRSQRY Number of consistent mode reads during parse
PRSCU Number of current mode block reads during parse
PSRMIS Number of library cache misses during parse
EXECNT Number of executes
EXECPU CPU time spent executing
EXEELA Elapsed time spent executing
EXEDSK Number of physical disk reads during execute
EXEQRY Number of consistent mode block reads during execute
EXECU Number of current mode block reads during execute
EXEROW Number of rows processed during execute
EXEMIS Number of library cache misses during the execute
FCHCNT Number of fetches
FCHCPU CPU time spent fetching
FCHELA Elapsed time spent fetching
FCHDSK Number of physical reads during fetch
FCHQRY Number of consistent mode blocks read during fetch
FCHCU Number of current mode blocks read during fetch
FCHROW Number of rows fetched
TKPROF formulates its output first for each individual SQL statement and then at the
user session level. It often pays to look at the "Overall Totals for All Statements" before
you examine individual statement performance. The overall totals will tell you what
general problems exist. Another time saver is to scan the TKPROF output file for
keywords. For example, in UNIX, you can scan the file using grep FULL trace.lis. The
word FULL is for full table scans.
Here are some rules for interpreting these statistics; these rules apply to all types of
systems and jobs:

• If the cpu, elap, and disk figures in the Parse row are high relative to
those in the Execute and Fetch rows, you probably need to enlarge your
 SHARED_POOL_SIZE so that you'll be able to store more of the dictionary in
memory. This will reduce the required amount of disk I/O.
• If the library cache misses are greater than 5% of the count, you should
tune your shared pool (see Chapter 11). The library cache misses are listed
between the statistics and the EXPLAIN PLAN details in your TKPROF output.
• If the Parse count figure is relatively high, you may need to do open
cursor tuning on the application.
• If the sum of Execute disk + Fetch disk is more than 10% of the sum of
Execute query + Execute current + Fetch query + Fetch current, the hit ratio of
finding data in the cache is too low. Consider tuning the statement by adding an
index or by using a more appropriate index, by rewriting the statement, by using
a hint, or by using a different optimizer option (e.g., FIRST_ROWS instead of
ALL_ROWS for an online system). You will often get a further improvement by
increasing the buffer cache using the INIT.ORA parameter
DB_BLOCK_BUFFERS.
• If the Fetch count is about twice Fetch rows, and if PL/SQL is being
used, it's likely that implicit cursors are in use. (Implicit cursors are SQL
statements that are not declared; they are less efficient than explicit cursors.)
Ask your analysts/programmers to investigate.
• If the total of the elap column is greater than 2.5 seconds, and if the
query is an interactive, online one, investigate the SQL statements. The response
times indicated by these statistics exceed the standards for most sites.
• If Execute query is high, and Execute rows and Execute current are
markedly lower, investigate your indexes. Your tables probably do not have
enough indexes or have inadequate indexes defined for them.

The following additional rules apply only to online transaction processing systems that
require excellent response time (e.g., 2.5 seconds elapsed for all online queries):

• Make sure all Execute cpu times are less than 1 second.

• Make sure Parse cpu times are less than 1 second. If not, tune your
shared pool, as documented in Chapter 11.
• Allow full table scans only on small tables. Don't allow them on tables
with more than 200 rows or on tables that are frequently used in multiple-table
joins.
• Remove all unnecessary calls to the system table, DUAL.
• Declare all PL/SQL SELECTs.
• Make sure Oracle chooses the appropriate driving table (described in
the section called "The driving table" in Chapter 6, Tuning SQL).

Take Care in Using TKPROF

TKPROF has a few traps that you'll want to avoid:

• If any changes have occurred to the schema, such as adding an index or

reanalyzing tables and/or indexes, the EXPLAIN PLAN results may be different
from what they were when the trace file was created.
• If you have obtained your trace file from the production database and
you are running TKPROF against your test or development database, the
execution plans may be different from what they were when the trace file was
created. This is the result of different statistics on tables and indexes. Other
factors that may cause the cost-based optimizer to act differently are the
DB_BLOCK_SIZE and DB_FILE_MULTIBLOCK_READ_COUNT setting;
the latter is used to determine whether a full table scan is preferable to an index
search.
• TKPROF does not know what data type bind variables are. It assumes
VARCHAR2. This may cause your EXPLAIN PLAN to appear as though an
index is not being used when in fact it is.
• The optimizer behavior can change from one release of Oracle to the
next, so you must make sure that you are running your TKPROF against the
same version of Oracle that was used to create the trace file.
• Do not use a different optimizer mode from the one that was used when
the trace file was created. RULE acts differently in the cost-based optimizer.
FIRST_ROWS also behaves differently from ALL_ROWS.