SQL*Plus autotrace command

Oracle Tips by Burleson Consulting

For any specific SQL query you can see SQL execution performance statistics. In
SQL*Plus you can issue the "set autotrace" command and then issue your SQL
statement:
SQL> set autotrace traceonly explain
SQL> select ename from emp where empno = 12;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'
2 1 INDEX (UNIQUE SCAN) OF 'PK_EMP' (UNIQUE)

Statistics
----------------------------------------------------------
83 recursive calls
0 db block gets
21 consistent gets
3 physical reads
0 redo size
221 bytes sent via SQL*Net to client
368 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed

The SQL*Plus autotrace command supports the following options:

• on – Enables all options.

• on explain – Displays returned rows and the explain plan.

• on statistics – Displays returned rows and statistics.

• trace explain – Displays the execution plan for a select statement without actually
executing it.
set autotrace trace explain

• traceonly – Displays execution plan and statistics without displaying the returned rows.
This option should be used when a large result set is expected.

For even more detailed SQL execution statistics, see the TKPROF (SQL Trace) utility.

Oracle tkprof Utility

Oracle TKPROF SQL_TRACE Setup

Tips for using the Oracle TKPROF Utility

Oracle Tips by Burleson Consulting
Don Burleson

Analyzing TKPROF Results

This is from the book Oracle Utilities: Using Hidden Programs, Import/Export, SQL Loader, oradebug,
Dbverify, Tkprof and More Order now and receive immediate access to the Online Code Depot!

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: