TKPROF Tips

So what should DBAs be looking for? Here’s a small checklist of items to watch for in tkprof formatted files:

• Compare the number of parses to number of executions. A well-tuned system will have one parse per n executions of a statement and will eliminate the re-parsing of the same statement.

• Search for SQL statements that do not use bind variables (:variable). These statements should be modified to use bind variables.

• Identify those statements that perform full table scans, multiple disk reads, and high CPU consumption. These performance benchmarks are defined by the DBA and need to be tailored to each database. What may be considered a high number of disk reads for an OLTP application may not even be minimal for a data warehouse implementation.

Uses for the tkprof utility:

• Compare the number of parses to number of executions.

• Search for SQL statements that do not use bind variables (:variable). These statements should be modified to use bind variables.

• Identify those statements that perform full table scans, multiple disk reads, and high CPU consumption.

The Oracle tkprof utility will be explained in six easy steps.

Step 1: Check the Environment

Before tracing can be enabled, the environment must first be configured by performing the following steps:

• Enable Timed Statistics – This parameter enables the collection of certain vital statistics such as CPU execution time, wait events, and elapsed times. The resulting trace output is more meaningful with these statistics. The command to enable timed statistics is:

ALTER SYSTEM SET TIMED_STATISTICS = TRUE;

• Check the User Dump Destination Directory – The trace files generated by Oracle can be numerous and large. These files are placed by Oracle in the user_dump_dest directory as specified in the init.ora. The user dump destination can also be specified for a single session using the alter session command. Make sure that enough space exists on the device to support the number of trace files that you expect to generate.

Step 2: Turn Tracing On

The next step in the process is to enable tracing. By default, tracing is disabled due to the burden (5-10%) it places on the database. Tracing can be defined at the session level:

ALTER SESSION SET SQL_TRACE = TRUE;

DBMS_SESSION.SET_SQL_TRACE(TRUE);

A DBA may enable tracing for another user’s session by using the following statement:

DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(sid,serial#,true);

The sid (Session ID) and serial# can be obtained from the v$session view. Once tracing with Oracle tkprof is enabled, Oracle generates and stores the statistics in the trace file. The trace file name is version specific.

- Enable Oracle tkprof tracing only on those sessions that are having problems.

- Explain Plan is not as useful when used in conjunction with tkprof since the trace file contains the actual execution path of the SQL statement. Use Explain Plan when anticipated execution statistics are desired without actually executing the statement.

- When tracing a session, remember that nothing in v$session indicates that a session is being traced. Therefore, trace with caution and remember to disable tracing after an adequate amount of trace data has been generated.

- tkprof does not control the contents of a trace file, it simply formats them. Oracle provides multiple ways to actually generate the trace file. tkprof is valuable for detailed trace file analysis. For those DBAs that prefer a simpler tracing mechanism with instant feedback, the autotrace utility should be used.

See complete directions for using TKPROF here:

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts.  You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.