Tips on Tuning Oracle Queries 20.05.

2016

1. First check, whether INDEX is used in your where clause or not ?

How to find INDEX Name and Columns associated with that INDEX :-
Select index_name, column_name
from all_ind_columns
where table_owner = IMIS
and table_name =
order by index_name, column_position ;
2. INDEX columns will be used in where clause in the same order in which INDEX was
created (if that is possible).
3. If INDEX is not exactly used (in where clause), then try to find nearby INDEX and use that
INDEX NAME in Hint.
Ex. Select /*+ index(<table name or alias> <index name>) */
4. In Join, use smaller table/view (in terms of records) as Leading object and use Hint. Also,
other than Join condition, there may be other filter condition(s) use that before Join
Statement.
Ex. Select /*+ leading(s y e) */
a, b, c
from s ,
y,
e
where s. = F1
and y. = s.
and e. = s.
5. Use equi-joins whenever possible, they improve SQL efficiency and use Indexes.
6. Do not use HINTS unless the performance gains clear.
7. Dont use ORDER BY clause unnecessary.
8. Never use ORDER BY clause in VIEW Definition.
9. Try to use UNION ALL in place of UNION. Also try, not to use DISTINCT (if possible). UNION
and DISTINCT both require Sort operation.
10.For huge queries, break up into smaller parts and put the result into TEMPORARY tables
(can create INDEX on this table also), and then from TEMPORARY tables pick up the final
result.
11.Minimize Database hitting. Write backend PL/SQLs and call that.
12.Select ONLY those columns in a query which are required. Extra columns which are not
actually used, incur more I/O on the database and increase network traffic.
13.There should not be any Cartesian product in the query unless there is a definite
requirement to do so.
14.Wherever multiple tables are used, always refer to a column by either using an alias or
using the fully qualified name. Do not leave the guess work to Oracle.
15.If possible use bind variables instead of constant/literal values in the filter conditions to
reduce repeated parsing of the same statement.
16.When writing sub-queries make use of the EXISTS operator where possible as Oracle
knows that once a match has been found it can stop and avoid a full table scan.
17.If the selective predicate is in the sub query, then use IN. If the selective predicate is in the
parent query, then use EXISTS.
18.Do not modify indexed columns with functions such as RTRIM, TO_CHAR, UPPER, TRUNC
etc. as this will prevent the optimizer from identifying the index. If possible perform the
modification on the constant side of the condition.
If the indexed column is usually accessed through a function (e.g NVL), consider creating a
function based index.
19.It is always better to write separate SQL statements for different tasks, but if you need to
use one SQL statement, then you can make a very complex statement, slightly less
complex, by using the UNION ALL operator.
20.Joins to complex views are not recommended, particularly joins from one complex view to
another.
21.Querying from a view requires all base tables against the view to be accessed for the data
to be returned. If that is not required, then do not use the view. Instead, use the base
table(s), or if necessary, define a new view.
22.While querying on a partitioned table try to use the partition key in the WHERE clause if
possible.
23.Consider changing the Hint to FIRST_ROWS(n) if the response time is important. The
default is ALL_ROWS which gives better throughput.
Select /*+ FIRST_ROWS */ .
24.Use CASE statements instead of DECODE (especially where nested DECODEs are involved)
because they increase the readability of the query immensely.
25.If Query requires quick response rather than good throughput is the objective, try to avoid
sorts (group by, order by, etc.). For good throughput, optimizer mode should be set to ALL
ROWS.
Select /*+ ALL_ROWS */
26.Consider using the PARALLEL Hint (only when additional resources can be allocated) while
accessing large data sets.

Points listed above are only pointers and may not work under every circumstance.

Following not Tune based, but common understanding :-

SQL statements should be formatted consistently to aid readability.
Use meaningful aliases for tables/views/cursors.