Best Practices_Oracle SQL_1

8/8/2019 Best Practices_Oracle SQL_1

http://slidepdf.com/reader/full/best-practicesoracle-sql1 1/6

ORACLE SQL QUERY TUNING

BEST PRACTICES

1



TABLE OF CONTENTS

Optimizing Process Flow ...................................................................................... 3

Utilizing Intended Indexes ................................................................................. 3

Object creation ..................................................................................................... 3

Multi-Threading Processes .................................................................................... 4

Usage of PL/SQL modules for Bulk collect .............................................................5

2



Optimizing Process Flow

First step in any tuning exercise is to optimize the process flow.

Review the process design to identify steps which can be combined or eliminated.

Identify alternatives which were not considered during development and possible because the

original design may have inherited legacy process flow or did not have a complete picture.

Utilizing Intended Indexes

Common reasons for not utilizing indexes are because of the use of functions in the indexes.

LEFT SIDE of the search condition

Some examples are given below:

Implicit conversion NVL to handle null columns

UPPER to handle case insensitive searches

Other possible reasons may include statistics on the tables and also the optimizer mode used. This

is related to the optimizer statistics and the different kinds of optimizer mode used at the database

level.

The optimizer will decide not to use the index if the where clause predicates for SQL statements

visit more data blocks.

In the where clauses, if the column data type is a number, do not use single quotes. Likewise, if

the column data type is varchar2 always use single quotes else indexes will not be used.

Do not use the ‘is null’ operator on a column that is indexed, as the optimizer will ignore the

index.

Object creation

Create the objects like tables and indexes in their respective tablespaces and also use proper extent sizes and naming conventions.

Use B-tree indexes where possible as they are the best choice to ensure good performance for a

wide variety of queries.

In cost-based optimizer, there is no relevance to the order of the where clause predicates. Only if

the leading column of an index is referenced in the where clause will the index be used else not.

3



Whenever you have a series of columns used in the WHERE clause, it is always better to use a

COMPOSITE INDEX on all the columns used in the WHERE clause, instead of having a

separate index on each of the columns.

Split the indexes if it has more than 4 columns .The bigger the index the less efficient it gets and

the optimizer might decide against using it .However this will be an exception incase of a

covering index .

In case the usage of functions is unavoidable, use FUNCTION-BASED INDEXES on the

respective columns. If varchar2 column is indexed and is compared against a number, index is

discarded. Instead compare the column after converting the number to character using TO_CHAR

function for the number value.

Multi-Threading Processes

Splitting processes into multiple concurrent sub-processes is called multi-threading a process.

Advantages of Multi-threading:

o Most effective on machines with multiple CPUs.

o Performance improves linearly with each CPU

o Can be used on any process which can be divided into multiple processes without having

to rewrite it.

o Achieved by adding a condition in the query to do a range of records rather than all

Remove unnecessary large-table full-table scans -

o Unnecessary full-table scans cause a huge amount of unnecessary I/O

o Identify unnecessary full scans and remove them by adding indexes or query tuning.

Verify optimal index usage –

o Materialize your aggregations and summaries for static tables. Use proper formatting for

the SQL queries. This will avoid Hard Parsing at the database level.

4



Usage of PL/SQL modules for Bulk collect

Usage of Cursors with Bulk Collect feature will help fetching multiple rows into one or more

collections.

Bulk Collect feature will help in collecting the output of multiple rows into one container and

then return the control to the PL/SQL engine.

The SQL engine automatically initializes and extends the collections. It starts filling the

collections at index 1, inserts elements consecutively (densely), and overwrites the values of any

elements that were previously defined.

For data immense queries, we can use the Limit parameter of the BULK FETCH and reduce the

overhead of memory.

Examples of Bulk fetch PL/SQL Procedure:

DECLARE

CURSOR emp_cur IS SELECT * FROM EMP;

TYPE emp_tab_t IS TABLE OF emp%ROWTYPE INDEX BY BINARY_INTEGER;

emp_tab emp_tab_t; -- In-memory table

rows NATURAL := 10000; -- Number of rows to process at a time

i BINARY_INTEGER := 0;

BEGIN

OPEN emp_cur;

LOOP

-- Bulk collect data into memory table - X rows at a time

FETCH emp_cur BULK COLLECT INTO emp_tab LIMIT rows;EXIT WHEN emp_tab.COUNT = 0;

DBMS_OUTPUT.PUT_LINE( TO_CHAR(emp_tab.COUNT)|| ' rows bulk fetched.');

FOR i IN emp_tab.FIRST .. emp_tab.LAST loop

-- Manipumate data in the memory table...

dbms_output.put_line('i = '||i||', EmpName='||emp_tab(i).ename);

END LOOP;

-- Bulk bind of data in memory table...

FORALL i in emp_tab.FIRST..emp_tab.LAST

INSERT /*+APPEND*/ INTO emp2 VALUES emp_tab(i);

END LOOP;CLOSE emp_cur;

END;

Do not code iterative single insert, update, or delete statements on a table within a PL/SQL loop

when they can be done in bulk.

5



Do not code correlated sub queries in applications, as they consume significant amounts of CPU

resources, use inline views instead. If a join will provide the functionality of the sub query try the

join method first.

6

Documents

Best Practices_Oracle SQL_1