Professional Documents
Culture Documents
EBS Tuning Guidelines
EBS Tuning Guidelines
Page 1
EBS Sql Tuning Guidelines Application Services
1. INTRODUCTION.........................................................................................................................................3
1.1 INTENT....................................................................................................................................................3
1.2 AUDIENCE...............................................................................................................................................3
2. OVERVIEW................................................................................................................................................3
2.1 PHYSICAL I/O.........................................................................................................................................3
2.2 DISK SORT..............................................................................................................................................4
2.3 RECURSIVE CALLS..................................................................................................................................4
3 PERFORMANCE TUNING.............................................................................................................................4
3.1 INDEX SUPPRESSION...............................................................................................................................4
3.2 COMPARING WRONG DATA TYPES..........................................................................................................5
3.3 FUNCTION-BASED INDEXES....................................................................................................................6
Creating the Function-based Index:.........................................................................................................6
3.4 USING THE ‘MINUS’ OPERATOR................................................................................................................7
3.5 USING THE ‘UNION’ OPERATOR................................................................................................................8
3.6 USING THE ‘ROWNUM’........................................................................................................................8
3.7 TRY TO AVOID ‘OR’ IF POSSIBLE............................................................................................................8
3.8 DEALING WITH INEQUALITIES................................................................................................................9
3.9 NESTED SUBQUERIES............................................................................................................................10
3.10 JOIN METHODS...................................................................................................................................12
3.10.1 NESTED LOOPS JOINS......................................................................................................................12
3.10.2 SORT-MERGE JOINS.........................................................................................................................12
3.10.3 CLUSTER JOINS................................................................................................................................13
3.10.4 HASH JOINS.....................................................................................................................................13
3.11 REDUCING SQL PARSING IN RECURSIVE PROCEDURES.....................................................................14
3.12 TRY TO MINIMIZE THE DISK SORTS.....................................................................................................16
4. RULES TO KEEP IN MIND.........................................................................................................................16
4.1 WATCH INDEXED WHERE CONDITIONS..............................................................................................16
4.2 WATCH NON-INDEXED WHERE CONDITIONS.....................................................................................17
4.3 CONSIDER IN OR UNION IN PLACE OF OR.........................................................................................18
4.4 WEIGH JOIN VERSUS EXISTS SUB-QUERY........................................................................................19
4.5 CONSIDER EXISTS IN PLACE OF DISTINCT.......................................................................................19
4.6 CONSIDER NOT EXISTS IN PLACE OF NOT IN..................................................................................19
4.8 ORDERING VIA THE WHERE CLAUSE.................................................................................................20
4.9 Use PL/SQL to reduce network traffic.................................................................................................20
Page 2
EBS Sql Tuning Guidelines Application Services
1. Introduction
1.1 Intent
This document is intended to help the developers to write efficient code during the development stage. Some of
the sqls have been presented with the corresponding elapsed times. These statistics are based on the
experiment results that were carried out in TCS offshore performance-engineering laboratory.
1.2 Audience
2. Overview
In general to tune a query we need to optimize the query execution path so that it utilizes system resources
efficiently and gets back the data with minimum Physical I/O.
Oracle database automatically performs sorting operations on row data as requested by any of the following
operations
Sorts that can’t fit into the sort_area_size will be paged out into the TEMP tablespaces for a disk sort. Disk sorts
are about 14,000 times slower than the memory sorts.
Recursive call occurs when one SQL statement requires the execution of a further separate SQL statement.
Page 3
EBS Sql Tuning Guidelines Application Services
DDL statements
Execution of SQL statements within stored procedures, packages, functions, and anonymous PL/SQL
blocks
Enforcement of referential integrity constraints
3 Performance Tuning
The below are some of the common methods to minimize the quantity of above discussed(Physical I/O,
Recursive Calls, disk sorts) in the oracle database and there by improve the performance of the system
Any function that modifies the column name in a WHERE clause will suppress the corresponding index. Many
Suppression Example; despite the intended hint to use the index, the SUBSTR function will suppress the index
The SUBSTR function was re-written with a LIKE instead and part of the index is used and the performance is
substantially increased:
Page 4
EBS Sql Tuning Guidelines Application Services
If you compare the wrong data types, your index may be suppressed internally. This is because Oracle will re-
write the query so that the comparison is correct. This problem is at times difficult to track down.
Tip: Comparing mismatched data types could cause an internal index suppression that is difficult to track down.
Oracle will often place a function on the column that fixes the mismatch, but suppresses the index.
Function-based indexes allow you to create an index based on a function or expression. Function-based indexes
can involve multiple columns, arithmetic expressions or may be a PL/SQL function or C callout. The following
An index has been created on the ename column when the UPPER function is used on this column.
Page 5
EBS Sql Tuning Guidelines Application Services
The function-based index (emp_idx) can be used for the query above. For large tables where the condition
retrieves a small amount of records, the query yields substantial performance gains over a full table scan.
select count(*)
from sample
where ratio(balance,limit) >.5;
The MINUS operator, for example, can be much faster than using WHERE NOT EXISTS or WHERE NOT IN
(SELECT). Following is an example of the power of the MINUS operator versus the NOT IN construct. First, the
NOT IN approach:
SELECT customer_id
FROM customers
WHERE area_code IN (402, 310)
AND zip_code NOT IN (68116, 68106);
Even if we have indexes on both the AREA_CODE and ZIP_CODE columns, the NOT IN predicate, to eliminate
two zip codes from the result set, will necessitate a full table scan. On the other hand:
SELECT customer_id
FROM customers
WHERE area_code IN (402, 310)
Page 6
EBS Sql Tuning Guidelines Application Services
MINUS
(SELECT customer_id
FROM customers
WHERE zip_code IN (68116, 68106);
The UNION operator, which is standard SQL and not peculiar to Oracle, is also a potential shortcut, especially
for a self-join with two noncontiguous index range values.
Following is an example of the UNION operator retrieving two noncontiguous result sets in a similar business
situation:
SELECT customer_id
FROM customer
WHERE area_code IN (402, 310)
UNION
SELECT customer_id
FROM customers
WHERE zip_code IN (31326, 31327);
Bear in mind that this only helps if the AREA_CODE and ZIP_CODE columns are left-most in the indexes.
Take advantage of ROWNUM. ROWNUM is a special pseudo-column that exists for every result set. It is quite
useful for limiting a potential runaway query and avoiding application grief. It refers to the relative row for a given
query, before any ORDER BY clause is applied. This is important to understand. If your statement looks like:
SELECT COUNT(*)
FROM customers
WHERE ROWNUM < 100
Oracle will select and return the first 99 rows and the query will halt. If you have a name search on a large table,
selecting WHERE NAME LIKE S% could easily return 100,000 rows or more. Rather than forcing your users to
logically qualify the query, you can add this row-limit qualifier to end the search when the upper limit is reached:
executing any sorts. This is a wonderful saving grace that you should use more often.
Placing indexes on statements having an OR clause and multiple WHERE conditions can be difficult. While in
previous versions it was essential to index at least one column in each clause OR’ed together, the merging of
indexes in the later versions of Oracle (V8+) becomes hazardous to the performance. Experiment with
Page 7
EBS Sql Tuning Guidelines Application Services
potentially suppression all indexes except the most limiting (retrieves the least amount of rows). Consider the
following examples:
select ENAME,DEPTNO,CITY,DIVISION
from EMP1
where EMPNO = 1
or ENAME = 'LONEY'
or DEPTNO = 10;
Execution Time: 4400 Seconds
Execution Plan:
TABLE ACCESS EMP1 FULL
The Solution:
Execution Plan:
TABLE ACCESS EMP1 ROWID
TABLE ACCESS EMP11 INDEX RS
The cost-based optimizer tends to have problems with inequalities. Since Oracle records the high and low value
for a column and assumes a linear distribution of data, problems occur when an inequality is used on a table with
a non-linear distribution of data. This can be solved by overriding the optimizer or by using histograms
Given:
Page 8
EBS Sql Tuning Guidelines Application Services
There are 5000 records (half the table) with an item number > 9990
The Optimizer chooses to use the index, since it believes there are only 10 rows to be retrieved:
The data and half the table will be retrieved by the query, and then we must suppress the index and substantially
increase performance. We suppress the index (and override the optimizer) since the query retrieves 50% of the
table (which is much more than the 5% or less rule for using the index)!
Tip: Strongly consider using hints to override the optimizer when using the “<“ and “>“ when the distribution of
data is not linear between the high & low values of a column. Histograms may also be employed.
Using nested sub queries instead of joining tables in a single query can lead to dramatic performance gains.
Only certain queries will meet the criteria for making this modification. When you find the right one, this trick will
take performance improvement to an exponentially better height. The conditions for changing a query to a
Tables are being joined to return the rows from ONLY one table.
Conditions from each table will lead to a reasonable percentage of the rows to be retrieved (more than 10%)
Page 9
EBS Sql Tuning Guidelines Application Services
The solution:
Page 10
EBS Sql Tuning Guidelines Application Services
The following are the various ways to join row sources together.
In a nested loops join, Oracle reads the first row from the first row source and then checks the second row
source for matches. All matches are then placed in the result set and Oracle goes on to the next row from the
first row source. This continues until all rows in the first row source have been processed. The first row source is
often called the outer table or driving table, while the second row source is called the inner table. This is one of
the fastest methods of receiving the first records back from a join.
Nested loops joins are ideal when the driving row source (the records that you’re looking for) is small and the
joined columns of the inner row source are uniquely indexed or have a highly selective non-unique index. Nested
loops joins have an advantage over other join methods in that they can quickly retrieve the first few rows of the
result set without having to wait for the entire result set to be determined.
In a sort-merge join, Oracle sorts the first row source by its join columns, sorts the second row source by its join
columns, and then “merges” the sorted row sources together. As matches are found, they are put into the result
set.
Sort-merge joins can be effective when lack of data selectivity or useful indexes render a nested loops join
inefficient, or when both of the row sources are quite large (greater than 5% of the records). However, sort-
merge joins can only be used for equijoins (WHERE D.deptno = E.deptno, as opposed to WHERE D.deptno >=
E.deptno). Also, sort-merge joins require temporary segments for sorting (if SORT_AREA_SIZE is set too small).
This can lead to extra memory utilization and/or extra disk I/O in the temporary tablespace.
A cluster join is really just a special case of the nested loops join. If the two row sources being joined are actually
tables that are part of a cluster and if the join is an equijoin between the cluster keys of the two tables, then
Oracle can use a cluster join. In this case, Oracle reads each row from the first row source and finds all matches
Page 11
EBS Sql Tuning Guidelines Application Services
Cluster joins are extremely efficient, since the joining rows in the two row sources will actually be located in the
same physical data block. However, clusters carry certain caveats of their own, and you can’t have a cluster join
without a cluster. Therefore, cluster joins are not very commonly used.
In a hash join, Oracle reads all of the join column values from the second row source, builds a hash table (in
memory if HASH_AREA_SIZE is large enough), and then probes the hash table for each of the join column
values from the first row source. This is like a nested loops join, except that first Oracle builds a hash table to
facilitate the operation. When using an ORDERED hint, the first table in the FROM clause is the driving table,
but only after the second table is loaded in the hash table. The first table then accesses the hash table for
matches. If enough memory is available (HASH_AREA_SIZE for the hash and DB_BLOCK_BUFFERS for the
Hash joins can be effective when the lack of a useful index renders nested loops joins inefficient. The hash join
might be faster than a sort-merge join in this case because only one row source needs to be sorted, and could
possibly be faster than a nested loops join because probing a hash table in memory can be faster than traversing
a B-tree index.
Description: Extensive SQL parsing can become a serious problem for a heavily loaded Oracle instance. This is
especially true if a SQL statement executed many times is also parsed many times. There are a number of
standard techniques and guidelines, which help reduce unnecessary parsing. In some special cases, though,
even following all the guidelines does not save you from extensive parsing. Find out below how to apply a
workaround in a specific situation to further reduce the parse-to-execute ratio of a statement.
The effect can be observed when a SQL cursor is used in a recursively-structured procedure. In such
procedures, very often a cursor is opened and for each fetched row the same procedure is called, which opens
the same cursor, etc. In most of the cases the recursive call is executed before the cursor is closed. As a result
of this, for each new "cursor open" a parse call is executed resulting in as many parses as executions.
Page 12
EBS Sql Tuning Guidelines Application Services
SELECT empno
FROM emp
WHERE mgr = p_mgr;
BEGIN
FOR c IN emp_mgr
LOOP
recurs(c.empno);
END LOOP;
END recurs;
As you can see the recursive call is executed before the (implicit) cursor is closed. The main idea for reducing
the parse calls is to first collect the results of the cursor (for example in a PL/SQL table), then close the cursor
and finally cycle through the results and perform the recursive procedure calls.
See below and example of such procedure (In this procedure I have used a bulk bind select, but a normal cursor
loop can be used too):
OPEN emp_mgr;
FETCH emp_mgr BULK COLLECT INTO p_empno;
i := emp_mgr%ROWCOUNT;
CLOSE emp_mgr;
FOR j IN 1..i
LOOP
recurs_close(p_empno(j));
END LOOP;
END recurs_close;
In the excerpts of the trace files generated during the procedure execution can be seen that the first procedure
has as many parses as executions (14), while the second has 1 parse only.
exec cursor_parse.recurs(7839);
SELECT empno
FROM emp
WHERE mgr = :b1
Page 13
EBS Sql Tuning Guidelines Application Services
exec cursor_parse.recurs_close(7839);
SELECT empno
FROM emp
WHERE mgr = :b1
Most of the important statistics are better for the execution of the recurs_close than the recurs procedure.
A sort operation can become problematic if it requires disk I/O for it to complete. The memory space
that can be used to perform a sort operation is controlled by the system parameter SORT_AREA_SIZE
and PGA_AGGREGATE_TARGET. If the sort is too large to be contained in the space determined by
the above parameters, oracle will continue the sort on disk. This is where performance problems can
begin to develop.
The below is the short list of some of the most commonly used SQL commands that can cause sorts
Page 14
EBS Sql Tuning Guidelines Application Services
IN, NOT IN
Aggregation functions (MAX, MIN, AVG, SUM)
Certain unindexed joins
Certain correlated subqueries
Since disk sort involves both physical reads and physical writes, try to avoid using distinct, order by, group by,
union, intersect, minus and some aggregate functions if the application permits.
Page 15
EBS Sql Tuning Guidelines Application Services
areacode = 972
areacode = 972
areacode = 972 or
IN example
state = 'TX‘ or
state = 'FL‘ or
state = 'OH‘
Page 16
EBS Sql Tuning Guidelines Application Services
state in ('TX','FL','OH')
UNION example
state = ‘TX’ or
areacode = 972
state = ‘TX’
union
areacode = 972
when the percentage of rows returned from the outer sub-query is high
when the percentage of rows returned from the outer sub-query is low
from employee e
from department d
Page 17
EBS Sql Tuning Guidelines Application Services
emp.deptno = dept.deptno
emp.deptno = dept.deptno)
Note – only has to find one match
avoid sub-queries that use NOT IN, use NOT EXISTS instead
deptstatus = ‘A’)
dept.deptno = emp.deptno)
a dummy WHERE clause referencing an indexed column will retrieve all records in ascending order not perform
a costly sort operation
Page 18
EBS Sql Tuning Guidelines Application Services
order by city
Good: select * from address where city > ‘’
Utilize PL/SQL to group related SQL commands and thereby reduce network traffic
Bad:
Good:
begin
end;
Page 19