Вы находитесь на странице: 1из 2

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

Page 1 of 2

Applies to:

Modified 13-OCT-2010

Type FAQ


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


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=

The cardinalities can be compared with the actual figures as collected by SQL_TRACE:


for each step in the query. These values are calculated using the statistics gathered on the objects with modifications

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 ------- ---------------------------------------------------






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
Note:212809.1 Limitations of the Oracle Cost Based Optimizer


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



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




Page 2 of 2


Keywords Page 2 of 2 AUTOTRACE; SQL_TRACE Back to top http s://su pport.oracle.com/CSP/ma in/article?cmd=show&t yp

Back to top