Tuning a New Query

8/10/2019 Tuning a New Query

1/4

6/24/2014 Document 372431.1

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

* TROUBLESHOOTING: Tuning a New Query (Doc ID 372431.1)Modified: 25-Aug-2013 Type: BULLETIN

In this Document

Purpose

Scope

DetailsReferences

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 howto 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 th ese steps also apply equally to cases where a query performs badly and used to perform well but only

the cu rren t 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 suggestsome suitable modifications. See:

Oracle Database Performance Tuning Guide10g Release 2 (10.2)Part Number B14211-03Chapter 12 Automatic SQL Tuning12.2 SQL Tuning Advisor

Note:271196.1 Automatic SQL Tuning - SQL Profiles.

2. Manual Query Tuning
http://-/?-http://-/?-https://support.oracle.com/epmos/faces/DocumentDisplay?id=271196.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=179668.1http://-/?-http://-/?-http://-/?-http://-/?-


2/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 outlinedbelow. Please note that query tuning, by its very nature is an advanced activity and often requires acomplete 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 datavolumes 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 datawas 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 thequery. For recommendations regarding statistics collection, See:

Note:44961.1 Statistics Gathering: frequency and strategy guidelinesNote:388474.1 * Recommendations for Gathering Optimizer Statistics on 9i

Note:605439.1 * Recommendations for Gathering Optimizer Statistics on 10gNote:749227.1 * Recommendations for Gathering Optimizer Statistics on 11g

Remember that regathering statistics has the potential to adversely affect numerous queries and so shouldbe 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), changingoptimizer 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 takeappropriate 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 givea hint as to where the optimizer thinks most resource is used. Hopefully this will give a strong hint as towhere 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 potentialproblem.

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?id=214106.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=207434.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=452011.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=749227.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=605439.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=388474.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=44961.1


3/4

6/24/2014 Document 372431.1


with row sources that return small numbers of rows or which eliminate significant amounts of data is oftencentral 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 especiallyuseful when there are large numbers of tables in a query as presenting just the join information makes itclear which joins are available based on the supplied join predicates. To construct a join graph, examine thewhere clause of the query and identify the join predicated. Each table involved in a join is written down anda line is drawn between them to indicate a join. Examining each join predicate produces a 'matrix' like joingraph.

Consider the following query:

SELECT dnameFROM emp, dept, bigempWHERE emp.deptno = dept.deptnoAND 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 beused 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 joinbigemp to dept would result in a cartesian product (there is no join predicate that joins bigemp to dept in thequery).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 informationgathered 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. tryplacing an object with very few rows at the start of the join order. Hopefully this will eliminate a significantproportion 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. Forexample, a query based upon object whose rows are eliminated based on a join predicate may performbetter if the object that it joins to is accessed before it so that the join values are present when that object isaccessed. Also, different, more efficient, access methods may be opened by changing the join order (e.g. apartitioned table where partitions are pruned based on a join predicate would usually need to follow thedriving 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?id=163563.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=67522.1


4/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 TuningNOTE:179668.1 - TROUBLESHOOTING: Tuning Slow Running QueriesNOTE:207434.1 - Tuning Queries: 'Quick and Dirty' SolutionsNOTE:214106.1 - Using TKProf to compare actual and predicted row countsNOTE:233112.1 - START HERE> Diagnosing Query Tuning ProblemsNOTE:271196.1 - Automatic SQL Tuning - SQL ProfilesNOTE:388474.1 - * How to Gather Optimizer S tatistics on 9iNOTE:44961.1 - Statistics Gathering: Frequency and Strategy GuidelinesNOTE:452011.1 - * Restoring Table Statistics (Oracle 10G Onwards)NOTE:605439.1 - * How to Gather Optimizer S tatistics on 10gNOTE:67522.1 - * Diagnosing Why a Query is Not Using an IndexNOTE:742112.1 - Troubleshooting Query Performance Degradation - Recommended ActionsNOTE:749227.1 - * How to Gather Optimizer S tatistics on 11g
https://support.oracle.com/epmos/faces/DocumentDisplay?id=749227.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=742112.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=67522.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=605439.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=452011.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=44961.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=388474.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=271196.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=233112.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=214106.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=207434.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=179668.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=163563.1https://support.oracle.com/epmos/faces/DocumentDisplay?id=122812.1

Tuning a New Query

Documents

Transcript of Tuning a New Query