Chapter: Example 3: Query1 Taking Too Long to Run

Problem Description
CustomerC is running an application and has identified a particular query that is taking over 45 minutes to complete, returning only one row.
Problem Analysis and Resolution
Step 1: Identified the Query
The customer was able to determine the problem query, using the application snapshot and dynamic SQL snapshot. The problem query was identified as:
select a.c2, b.c2, c.c3 from a,b,c where a.c1=b.c1 and b.c2=c.c2 and c.c3=a.c3 and c.c1=50193
Step 2: Run Explain for the SQL Statement
The explain plan for the SQL statement indicated the following:
Estimated Cost = 2968724 Estimated Cardinality = 99996
The DBA knew that, because the column C1 in the table C is a primary key, there can be a maximum of only one row returned by the SQL statement. Therefore, the estimated cardinality in the access plan is not correct. A difference in the expected cardinality and the optimizer's estimated cardinality this large is normally due to old or nonexistent statistics.
Step 3: Check to Determine Whether the Tables' Statistics Are Current
To determine when the last time statistics were gathered for these three tables, use the following statement:
select stats_time from syscat.tables where tabname in ('A','B','C')
The output of the above statement was:
STATS_TIME ------------------------- - - - 3 record(s) selected.
Therefore, the tables do not have current statistics.
Step 4: Gather Statistics for the Tables
To gather statistics, use the RUNSTATS command as follows:
runstats on table user.a with distribution and detailed indexes all runstats on table user.b with distribution and detailed indexes all runstats on table user.c with distribution and detailed indexes all
Step 5: Retest
After running the RUNSTATS command for all of the tables in the statement, it was able to complete in less than two seconds, and the explain plan indicated the following:
Estimated Cost = 183 Estimated Cardinality = 1
![]() | Advanced dba certification guide and reference |







