ORACLE SQL TUNING:-

Check the SQL execute statement

• As a rule of thumb, tables should be joined from smallest effective number rows to largest effective
number of rows
For Eg,
Suppose that there are 10 departments and 1000 employees, and that the inner table in each query has
an index on the join column. In the first query, the first table produces 10 qualifying rows (in this case,
the whole table). In the second query, the first table produces 1000 qualifying rows. If in the join order
we have the first query will access the EMP table 10 times and scan the DEPT table once. The second
query will scan the EMP table once but will access the DEPT table 1000 times. Therefore the first
query will perform much better
• We can avoid Transformed Columns in the WHERE Clause. e.g., substr, trunc etc.
Do not use SQL functions in predicate clauses or WHERE clauses. Any expression using a column,
such as a function having the column as its argument, causes the optimizer to ignore the possibility of
using an index on that column, even a unique index, unless there is a function-based index defined that
can be used.
• I would avoid the LIKE predicate = Always replace a "like" with an equality, when appropriate.
• I would avoid mixing data types - If a WHERE clause column predicate is numeric, do not to use
quotes. For char index columns, always use quotes. There are mixed data type predicates.
• To improve SQL efficiency, use equijoins whenever possible. Statements that perform equijoins on
untransformed column values are the easiest to tune, e.g. using Predicates AND and =.
• Would like to avoid correlated subquery by replacing with join (Inline view), as join will work faster
than correlated query.
• Union All will work faster than Union, and if we don’t care about the redundant data.
• Proper use of table aliases when referencing columns.
• Rewrite complex subqueries with temporary tables
• I will make use of SQL analytic functions - The Oracle analytic functions can do multiple aggregations
(e.g. rollup by cube) with a single pass through the tables, making them very fast for reporting SQL.
• Consider the alternative EXISTS, IN and table joins when doing multiple table joins. None of these are
consistently faster; it depends on your data.
In general, if the selective predicate is in the subquery, then use IN. If the selective predicate is in the
parent query, then use EXISTS.
(A predicate is the syntax used to specify a subset of rows to be returned. Predicates are specified in
the WHERE clause of a SQL statement.)

Oracle Optimizer
The optimizer is the part of the Oracle Server that creates the execution plan for a SQL statement. An
execution plan is a series of operations that are performed to execute the statement. The optimizer uses
various pieces of information to determine the best path:

• Hints supplied by the developer

• Statistics
• Information in the dictionary
• WHERE clause

The optimizer usually works in the background. However, with diagnostic tools such as EXPLAIN and
SQL*Plus AUTOTRACE, you can see the decisions that the optimizer makes.
The optimizer determines the least-cost plan (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.

The factors considered by the optimizer are:

• Access path
• Join order
• Join method

Access paths

• Full-table scans
• Row ID scans
• Index scans
• Cluster scans
• Hash scans

Join order

A join order is the order in which different join items (such as tables) are accessed and joined together.

Join Methods

The different join methods considered by the optimizer are:

• Nested-loop join
• Hash join
• Sort-merge join
• Cartesian join

Using hints to tune Oracle SQL

Among the most common tools for tuning SQL statements are hints. A hint is a directive that is added to
the SQL statement to modify the access path for a SQL query.

• Self-order the table joins - If you find that Oracle is joining the tables together in a sub-optimal
order, you can use the ORDERED hint to force the tables to be joined in the order that they appear in
the FROM clause.

• Try a first_rows_n hint. Oracle has two cost-based optimizer modes, first_rows_n and all_rows.
The first_rows mode will execute to begin returning rows as soon as possible, whereas the all_rows
mode is designed to optimize the resources on the entire query before returning rows.

SELECT /*+ first_rows */