6/24/2014

Document 372431.1

* TROUBLESHOOTING: Tuning a New Query (Doc ID 372431.1)

Modified: 25-Aug-2013

Type: BULLETIN

In this Document
Purpose
Scope
Details
References

APPLIES TO:
Oracle Database - Enterprise Edition - Version 6.0.0.0 to 11.1.0.7 [Release 6.0 to 11.1]
Information in this document applies to any platform.
***Checked for relevance on 25-Aug-2013***

PURPOSE
This article Provides information regarding how to tune a newly written query.

SCOPE
Aimed at Oracle Support Analysts, DBA's and Application Developers

DETAILS
A new query that performs badly is typified by a lack of historical information that may provide guidance as to how
to encourage it to perform more acceptably.
There is likely to be no known 'good' access path.
If there is a known 'good' access path then please see:
Note.179668.1 * TROUBLESHOOTING: Tuning Slow Running Queries

Note that these steps also apply equally to cases where a query performs badly and used to perform well but only
the current plan is available, or for any case where no 'target' plan is available for the query.
1. Use the SQL Tuning Advisor
Since there is no known target access path, a good strategy is to use the SQL Tuning Advisor to suggest
some suitable modifications. See:
Oracle Database Performance Tuning Guide
10g Release 2 (10.2)
Part Number B14211-03
Chapter 12 Automatic SQL Tuning
12.2 SQL Tuning Advisor
Note:271196.1 Automatic SQL Tuning - SQL Profiles.

2. Manual Query Tuning

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_513&id=372431.1

1/4

6/24/2014

Document 372431.1

If you are unable to use the advisor, then the manual steps that you need to perform are outlined
below. Please note that query tuning, by its very nature is an advanced activity and often requires a
complete understanding of the environment where the database resides.

Consider the feasibility of the query

Please consider that it may be that the reason that this query cannot run quickly is because of the data
volumes involved and the way in which the query is designed.
It may be that a total rethink is required.
Maybe the query would run better if it was handled procedurally or by using parallel execution or if the data
was split up in to more manageable portions that could be executed separately
Make sure that all the optimizer statistics (using histograms where appropriate) are up to date then retry the
query. For recommendations regarding statistics collection, See:
Note:44961.1 Statistics Gathering: frequency and strategy guidelines
Note:388474.1 * Recommendations for Gathering Optimizer Statistics on 9i
Note:605439.1 * Recommendations for Gathering Optimizer Statistics on 10g
Note:749227.1 * Recommendations for Gathering Optimizer Statistics on 11g
Remember that regathering statistics has the potential to adversely affect numerous queries and so should
be embarked on with caution. From 10gR2 statistics can be restored using:
Note:452011.1 * Restoring table statistics in 10G onwards
Briefly use Trial and error tactics to attempt to find an acceptable plan.
These might include: Forcing a different optimizer (RULE/ALL_ROWS/FIRST_ROWS hints), changing
optimizer related parameters, different oracle version etc. Also see:
Note:207434.1 Tuning Queries: 'Quick and Dirty' Solutions
Examine the bad plan.
Maybe there is an obvious full tablescan on a table where an index would be more appropriate. Then take
appropriate steps to resolve this such as adding appropriate hints.
Are there missing objects?.
It is possible that extra objects (such as indexes) are required to enhance the performance of the query.
Look into the design of the application with regard to this query and see if it is feasible to add (or remove)
indexes.
Compare plan values with real figures.
If the query is running under the Cost Based Optimizer (CBO), then the Cost and Cardinality figures may give
a hint as to where the optimizer thinks most resource is used. Hopefully this will give a strong hint as to
where effort should be concentrated. These cardinality figures can be compared with counts (count(*)) of
the tables with and without the table predicates applied to spot differences which could indicate a potential
problem.
Optimizer figures can also be compared to TKProf output. See:
Note:214106.1 Using TKProf to compare actual and predicted row counts
Use Cardinality figures
Cardinality figures are useful for determining candidates for driving the query. Processing a query by starting
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_513&id=372431.1

2/4

6/24/2014

Document 372431.1

with row sources that return small numbers of rows or which eliminate significant amounts of data is often
central to obtaining an acceptable plan.
Construct a join order graph for the query.
A join graph illustrates which tables are joined to each other in a query. Drawing a join graph is especially
useful when there are large numbers of tables in a query as presenting just the join information makes it
clear which joins are available based on the supplied join predicates. To construct a join graph, examine the
where clause of the query and identify the join predicated. Each table involved in a join is written down and
a line is drawn between them to indicate a join. Examining each join predicate produces a 'matrix' like join
graph.
Consider the following query:
SELECT dname
FROM emp, dept, bigemp
WHERE emp.deptno = dept.deptno
AND emp.empno = bigemp.empno

This query has a join between emp and dept and a join between emp and bigemp.
The join graph for this would be:bigemp -- emp -- dept.
The join graph for a query helps the analyst to visualise alternative join orders and start points that could be
used for a query. It also helps identify join orders that may not be advisable and Cartesian Products (i.e.
where a join may be missing).
In the example above forcing a join order of bigemp -- dept -- emp may be inadvisable as trying to join
bigemp to dept would result in a cartesian product (there is no join predicate that joins bigemp to dept in the
query).
N.B cartesian products are not necessarily a bad thing. With low data volumes (and especially where one of
the row sources contains 1 row) they can provide good performance.
Choose a join order and force it using the ORDERED hint.
Often there are many different options here. Combining table specific predicate and cardinality information
gathered earlier with the join order information can identify a sensible driving point for the query. Initially,
choose a join order that eliminates as many rows as possible early in the query execution plan (e.g. try
placing an object with very few rows at the start of the join order. Hopefully this will eliminate a significant
proportion of whatever row source it is joined to). If this does not give an acceptable plan then try different
join orders.
Be careful of related objects
Bear in mind that certain objects may perform more efficiently if they follow other related objects. For
example, a query based upon object whose rows are eliminated based on a join predicate may perform
better if the object that it joins to is accessed before it so that the join values are present when that object is
accessed. Also, different, more efficient, access methods may be opened by changing the join order (e.g. a
partitioned table where partitions are pruned based on a join predicate would usually need to follow the
driving row source in a nested loop join in order for partition elimination to occur.
See the Does the join order allow index usage?section in
Note:67522.1 * Diagnosing Why a Query is Not Using an Index
for more information on this process.
Consider more advanced techniques.
Refer to RELATED DOCUMENTS below.
In particular, see:
Note:163563.1 * TROUBLESHOOTING: Advanced Query Tuning
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_513&id=372431.1

3/4

6/24/2014

Document 372431.1

REFERENCES
NOTE:122812.1 - * TROUBLESHOOTING: Tuning Queries That Cannot be Modified (10g and below)
NOTE:163563.1 - * TROUBLESHOOTING: Advanced Query Tuning
NOTE:179668.1 - TROUBLESHOOTING: Tuning Slow Running Queries
NOTE:207434.1 - Tuning Queries: 'Quick and Dirty' Solutions
NOTE:214106.1 - Using TKProf to compare actual and predicted row counts
NOTE:233112.1 - START HERE> Diagnosing Query Tuning Problems
NOTE:271196.1 - Automatic SQL Tuning - SQL Profiles
NOTE:388474.1 - * How to Gather Optimizer Statistics on 9i
NOTE:44961.1 - Statistics Gathering: Frequency and Strategy Guidelines
NOTE:452011.1 - * Restoring Table Statistics (Oracle 10G Onwards)
NOTE:605439.1 - * How to Gather Optimizer Statistics on 10g
NOTE:67522.1 - * Diagnosing Why a Query is Not Using an Index
NOTE:742112.1 - Troubleshooting Query Performance Degradation - Recommended Actions
NOTE:749227.1 - * How to Gather Optimizer Statistics on 11g

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_513&id=372431.1

4/4