Escolar Documentos
Profissional Documentos
Cultura Documentos
Version : 0.1
Date : 21.05.2010
Status : Draft
Author : Midhun M
Pages : 14
References
1. Oracle® Database Performance Tuning Guide 10g Release 2 (10.2)
2. http://www.orafaq.com/wiki/Oracle_database_Performance_Tuning_FAQ
3. http://www.akadia.com/services/ora_interpreting_explain_plan.html
SQL Queries
Table of Contents
1 Introduction ......................................................................................................4
2 Objective............................................................................................................4
3 Basic information about query tuning.............................................................4
3.1 How does Oracle access data? .................................................................................4
3.2 Full table scan..........................................................................................................4
3.3 Index lookup..............................................................................................................5
4.3.1 Index Unique Scans.....................................................................................5
4.3.2 Index Range Scans......................................................................................5
4.3.3 Index Full Scans...........................................................................................5
4.3.4 Index Fast Full Scans...................................................................................5
3.4 EXPLAIN PLAN Usage..............................................................................................6
3.5 SQL Hints..................................................................................................................6
4.3.5 Why using hints............................................................................................7
3.6 Managing Statistics for Optimal Query Performance.................................................7
4.3.6 How to Generate Oracle Statistics................................................................7
4 Case Study..........................................................................................................8
4.1 About the view and base tables..................................................................................8
4.3.7 View: VW_VSP_NONZEBRA_REMAP........................................................8
4.3.8 Table: CHECKSHOT_SURVEY_...............................................................10
4.3.9 Table: CHECKSHOT_SURVEY_..............................................................10
4.3.10 Table: CHECKSHOT_SURVEY_.............................................................10
4.2 Execution plan before the modifications made.........................................................10
4.3 Modifications made..................................................................................................12
4.4 Execution plan after modifications .........................................................................12
5 Best practices..................................................................................................14
SQL Queries
1 Introduction
This document describes the basic information about the query tuning with an example.
Since we are dealing with information management it more often deals with retrieving
and persisting data through queries. So it is most important to optimize / tune the query
performance. Otherwise this will lead to poor performance of system, taking long time to
retrieve data. When I analyzed one of the views which was taking more time to retrieve, I
found this is because of improper scripting, and needs optimization/tuning for improving
performance. By this document I mean to address tuning basics, impact of that, some
recommendations, best practices etc.
2 Objective
• To provide basic information about query tuning.
• To provide some tips and information on query tuning with an example based on
VW_VSP_NONZEBRA_REMAP view.
At the physical level Oracle reads blocks of data. The smallest amount of data read is a
single Oracle block, the largest is constrained by operating system limits (and multiblock
i/o). Logically Oracle finds the data to read by using the following methods:
Full table scan happens when oracle has to scan entire table to return the result for the
query. In Oracle, a full-table scan is performed by reading all of the table rows, block by
block, until the high-water mark for the table is reached. As a general rule, full-table
scans should be avoided unless the SQL query requires a majority of the rows in the
table.
Any one of the following conditions will cause Oracle to invoke a full-table scan:
• When no indexes exist for the table
• When a query does not contain a where clause
• When an indexed column is invalidated by placing it inside a BIF
• When a query uses the like operator, and it begins with a ‘%’
• With the cost-based optimizer, when a table contains a small number of rows
• When the optimizer_mode=all_rows in the initialization file
SQL Queries
In this method, a row is retrieved by traversing the index, using the indexed column
values specified by the statement. An index scan retrieves data from an index based on
the value of one or more columns in the index. To perform an index scan, Oracle
searches the index for the indexed column values accessed by the statement. If the
statement accesses only columns of the index, then Oracle reads the indexed column
values directly from the index, rather than from the table.
SQL Queries
When an SQL statement is passed to the server the Cost Based Optimizer (CBO) uses
database statistics to create an execution plan which it uses to navigate through the
data. Once you've highlighted a problem query the first thing you should do is EXPLAIN
the statement to check the execution plan that the CBO has created. This will often
reveal that the query is not using the relevant indexes, or indexes to support the query
are missing. Interpretation of the execution plan is beyond the scope of this article.
The EXPLAIN PLAN method doesn't require the query to be run, greatly reducing the
time it takes to get an execution plan for long-running queries.
Explained.
SQL>
The explain plan process stores data in the PLAN_TABLE. Then the execution plan
displayed using,
For more information about the explain plan and how to interpret the explain plan please
refer Oracle® Database Performance Tuning Guide 10g Release 2 (10.2).
With hints one can influence the optimizer. The usage of hints causes Oracle to use the
Cost Based optimizer.
Example:
SQL Queries
4.3.5 Why using hints
It is a perfect valid question to ask why hints should be used. Oracle comes with
an optimizer that promises to optimize a query's execution plan. When this
optimizer is really doing a good job, no hints should be required at all.
Sometimes, however, the characteristics of the data in the database are
changing rapidly, so that the optimizer (or more accuratly, its statistics) are out of
date. In this case, a hint could help.
The optimizer’s job is to take SQL statements and decide how to get the data that is
being asked for in the SQL statement and how to get it in the quickest way possible.
When a SQL statement is executed, the database must convert the query into an
execution plan and choose the best way to retrieve the data. These execution plans are
computed by the Oracle cost-based SQL optimizer commonly known as the CBO.
The choice of executions plans made by the Oracle SQL optimizer is only as good as
the Oracle statistics. To always choose the best execution plan for a SQL query, Oracle
relies on information about the tables and indexes in the query. The optimizer program
uses statistics on tables and on the indexes surrounding those tables, so it’s important to
have statistics on both.
If new objects are created, or the amount of data in the database changes the statistics
will no longer represent the real state of the database so the CBO decision process may
be seriously impaired.
This command will generate statistics on all tables in the SCOTT schema. Since
we included the cascade command, the indexes will also have statistics
generated on them. This is important, you need statistics on indexes as well as
on tables in Oracle!
If you create a new table, or the amount of data in the table changes then it may
not be practical or desirable to re-generate statistics on the entire schema if the
schema is quite large and the database is very busy. Instead you will use the
dbms_stats.gather_table_stats command to generate statistics for a single table,
and optionally for related table indexes. Here is an example:
In this case we are generating statistics for the EMP table in the SCOTT schema.
Again we use the cascade parameter to insure all of the indexes get analyzed.
SQL Queries
4 Case Study
4.1 About the view and base tables
SQL Queries
br.id = cs.borehole_id
and cs.name='Checkshot_Hdr-NonZebra_Remap'
order by cs.id,br.ubhi,cs.acquisition_date,cs.correction_velocity,
cs.datum_elevation,cs.index_correction, cs.remarks) hdr,
(select cs.id,
br.ubhi,
cs.acquisition_date,
tdp.depth md,
tdp.travel_time tvd_brt,
br.id borehole_id,
tdp.version
from borehole br,
checkshot_survey cs,
time_depth_pair tdp
where br.id=cs.borehole_id
and cs.name='Checkshot_MD-TVDBRT-NonZebra_Remap'
and cs.id=tdp.checkshot_id
and tdp.name='MeasuredDepth_TVDBRT-NonZebra_Remap'
order by cs.id,br.ubhi,cs.acquisition_date,tdp.depth,tdp.travel_time) tvdbrt,
(select cs.id,
br.ubhi,
cs.acquisition_date,
tdp.depth md,
tdp.travel_time tvd_brt,
br.id borehole_id,
tdp.version
from borehole br,
checkshot_survey cs,
time_depth_pair tdp
where br.id=cs.borehole_id
and cs.name='Checkshot_MD-TVDSS-NonZebra_Remap'
and cs.id=tdp.checkshot_id
and tdp.name='MeasuredDepth_TVDSS-NonZebra_Remap'
order by cs.id,br.ubhi,cs.acquisition_date,tdp.depth,tdp.travel_time) tvdss,
(select cs.id,
br.ubhi,
cs.acquisition_date,
tdp.depth md,
tdp.travel_time tvd_brt,
br.id borehole_id,
tdp.version
from borehole br,
checkshot_survey cs,
time_depth_pair tdp
where br.id=cs.borehole_id
and cs.name='Checkshot_MD-TWTSS-NonZebra_Remap'
and cs.id=tdp.checkshot_id
and tdp.name='MeasuredDepth_TWTSS-NonZebra_Remap'
order by cs.id,br.ubhi,cs.acquisition_date,tdp.depth,tdp.travel_time) twt
WHERE hdr.ubhi = tvdbrt.ubhi and
hdr.acquisition_date = tvdbrt.acquisition_date and
hdr.work_order_number=tvdbrt.borehole_id||'-NonZebra_Remap' and
tvdbrt.ubhi=tvdss.ubhi and
tvdbrt.acquisition_date=tvdss.acquisition_date and
tvdbrt.md=tvdss.md and
tvdbrt.version=tvdss.version and
tvdbrt.ubhi=twt.ubhi and
tvdbrt.acquisition_date=twt.acquisition_date and
SQL Queries
tvdbrt.md=twt.md and
tvdbrt.version=twt.version
GROUP BY hdr.ubhi,
hdr.name,
hdr.acquisition_date,
tvdbrt.md,
tvdbrt.version
ORDER BY hdr.ubhi,
hdr.name,
hdr.acquisition_date,
tvdbrt.md;
A SQL statement can be executed in many different ways, such as full table scans,
index scans, nested loops, and hash joins. The query optimizer determines the most
efficient way to execute a SQL statement after considering many factors related to the
objects referenced and the conditions specified in the query. This determination is an
important step in the processing of any SQL statement and can greatly affect execution
time.
Execution plan is basically a step by step instruction for how the statement must be
executed. That is, the orders in which tables are read, if indexes are used, which join
methods are used to join tables and so on.
COUNT(*)
----------
31326
Elapsed: 00:56:09.48
Note: The time taken for executing this query is approximately 1 hour.
SQL Queries
From the execution plan it is very clear that the 3 select queries in the view creation
script is going for INDEX RANGE SCAN (TIME_DEPTH_PAIR_FI01) and the number of
rows returned is 13431 for each select statement.
SQL Queries
I/O calls, and making fewer large I/O calls is cheaper than making many smaller
calls.
Since we are accessing a large number of rows, full table scan on TIME_DEPTH_PAIR_
is always better than INDEX RANGE SCAN.
Index created.
Index dropped.
Recommends you to gather the statistics of all the base tables involved. These statistics
are used by the query optimizer to choose the best execution plan for each SQL
statement.
'CHECKSHOT_SURVEY_',cascade=>TRUE);
'TIME_DEPTH_PAIR_',cascade=>TRUE);
'BOREHOLE_',cascade=>TRUE);
COUNT(*)
SQL Queries
-----------
31326
Elapsed: 00:00:04.51
• From the execution plan it is very clear that the query optimizer is going for a full
table scan on TIME_DEPTH_PAIR_ rather than INDEX RANGE SCAN.
• Rows returned from the driver table (TIME_DEPTH_PAIR_) is around 310.
Result: The time taken for the select query has been reduced significantly (1 hour
to 5 seconds)
SQL Queries
5 Best practices
• Indexes are created when frequently less than 15% rows of a table are retrieved
or on columns used in joins to improve join performance.
• Columns that are recommended to be indexed are those, whose values are
unique or there are few duplicate entries, having a wide range of values (suitable
for regular index), or having a small range of values (suitable for bitmap indexes).
• The database can use indexes more effectively when statistical information about
the tables involved in queries are gathered.
• Indexes can be dropped if they are no longer required. In circumstances when
index do not speed up queries or the queries in the application do not use the
index, index is usually dropped.
• Gather the table statistics if a new table is created or altered.
• Gather the table statistics when the amount of data changes in the table is huge.
SQL Queries