Page 1 of 2

Using TKProf to compare actual and predicted row counts [ID 214106.1]

Modified 13-OCT-2010 Type FAQ Status PUBLISHED

Applies to:

Oracle Server - Enterprise Edition

Information in this document applies to any platform.
***Checked for relevance on 13-Oct-2010***

Purpose

Explain how TKProf can be used to highlight differences in predicated and actual row counts to identify potential optimizer problems.

Questions and Answers

SQL_TRACE combined with TKProf can provide some very useful information to assist with the tuning of queries when compared against Explain plan output.

Especially useful for tuning SQL are the actual row counts as these can be compared against the optimizer's predicted row counts. Expected row counts (cardinalities e.g. Card=12345) can
optimized using the Cost Based Optimizer (CBO). Actual row counts can be found in tkprof output or in the STAT lines from raw <> (or <> output ). Any anomalies can then be investigated.

For example, if the actual number of rows returned by a particular explain plan step differs significantly from the CBO's cardinality estimates, then it is possible that this is a source of a bad p
incorrect statistics can be investigated and corrected.

Consider the following statement:

SELECT ename FROM emp e, dept d WHERE e.deptno=d.deptno;

The execution plan from autotrace (containing cost and cardinality information) can be compared with the actual row counts displayed against the raw trace file or the tkprof explain plan:

Autotrace output:

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=5 Card=14 Bytes=126)
1 0 HASH JOIN (Cost=5 Card=14 Bytes=126)
2 1 TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=14 Bytes=98)
3 1 TABLE ACCESS (FULL) OF 'DEPT' (Cost=2 Card=4 Bytes=8)

The autotrace output shows the expected cardinality figures (Card=...) for each step in the query. These values are calculated using the statistics gathered on the objects with modifications a
The cardinalities can be compared with the actual figures as collected by SQL_TRACE:

Raw trace file:

STAT #1 id=1 cnt=14 pid=0 pos=1 obj=0 op='HASH JOIN '

STAT #1 id=2 cnt=14 pid=1 pos=1 obj=44913 op='TABLE ACCESS FULL EMP '
STAT #1 id=3 cnt=4 pid=1 pos=2 obj=42480 op='TABLE ACCESS FULL DEPT '

The cnt value in the relevant 'STAT' line for the query shows the row count for each step of the recorded plan (the number immediately after the STAT # indicates the cursor that the statistic
TKProf to give the following output:

Formatted tkprof explain plan:

Rows Row Source Operation

------- ---------------------------------------------------
14 HASH JOIN
14 TABLE ACCESS FULL EMP
4 TABLE ACCESS FULL DEPT

The cardinality and row figures for each step should be the same. If they are not then this may indicate thats there is a problem in the way the base statistics have been gathered (no data sa
skewed data etc) or some deficiency in the cardinality computation method.

The Cost Based optimizer has a few limitations to its model that affects queries in a small number of cases. These limitations are documented in the following article:

Note:212809.1 Limitations of the Oracle Cost Based Optimizer

References

NOTE:212809.1 - Limitations of the Oracle Cost Based Optimizer

NOTE:43214.1 - AUTOTRACE Option in SQL*Plus
NOTE:163563.1 - * TROUBLESHOOTING: Advanced Query Tuning
NOTE:62160.1 - Tracing Sessions in Oracle Using the DBMS_SUPPORT Package
NOTE:39817.1 - Interpreting Raw SQL_TRACE and DBMS_SUPPORT.START_TRACE output
NOTE:199081.1 - Overview Reference for SQL_TRACE, TKProf and Explain Plan

Related

Products

z Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=214106.1 11/7/2010
 Page 2 of 2

Keywords

AUTOTRACE; SQL_TRACE

Back to top

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=214106.1 11/7/2010