performance tuning guidelines

8/7/2019 performance tuning guidelines

1/4

Code Review guidelines:

MUST DOs during a code review :

1. Get an Explain Plan and study all cursors and sqls.

2. Dont consider the current elapsed time as a measure of performance becausethe code review is done on development database and the data volume in it is notrealistic or comparable to Production.

3. Look out for full table scans and try tuning SQL to avoid them.

Things to look for while doing a code review :

1. Always Use select count(indexed_column) , as it will use index.

select count( indexed_ column) from table [Most Efficient]select count(*) from table [Close Second]

select count( 1) from table [Distant Third].

2. Breakup the DECODE in the where clause.

Bad -DECODE (warehouse_id, 1, 'Southlake',

a. 2, 'San Francisco',b. 3, 'New Jersey',

c. 4, 'Seattle',d. 'Non-domestic') = new_location

Good -

((warehouse_id = 1 and new_location = 'Southlake') OR

(warehouse_id = 2 and new_location = 'San Francisco') OR(warehouse_id = 3 and new_location = 'New Jersey') OR

(warehouse_id = 4 and new_location = 'Seattle') OR( new_location = 'Non-domestic') )

3. Rewrite the NVL in where clause

Bad -NVL(this_value, 99) = other_value

Good -

(this_value is null and other_value = 99) OR(this_value is not null and this_value = other_value)

4. If possible, consider to rewrite TRUNC in where clause.

Bad -

TRUNC(start_date) = to_char(29-JUL-2002,DD-MON-YYYY)

Good -start_date > one_date 1 AND start_date


2/4

5. Try to avoid using functions on indexed columns.

6. When index scan performs more block visitations than a full table scan, betterto use full table scans

7. Fast full table scans are an alternative to full table scans when the indexcontains all the columns that are needed for the query.

8. Consider bitmapindexes when where clause predicate contain low-

cardinality columns, contain logical operations such as OR,AND or NOT onthose columns.

9. For very complex queries with many OR conditions , consider rewriting them

using UNIONALL

10. Make use of composite indexes. These need to be ordered in the

decreasing order of selectivity.

11. If your query contains subqueries , tune them.

12. If a join will provide you the with functionality of the subquery, try the join

method first, before trying the subquery method.

13.Use NOT EXISTS instead of NOT IN in the where clause predicates.

Bad -select * from emp where

deptno not in (select deptno from dept where deptstatus = A)

Good -

select * from emp wherenot exists (select X from dept wheredeptstatus = Aand

dept. deptno = emp. deptno).

14.Consider to use LIKE operator instead of SUBSTR function.

Bad -SUBSTR(column_name,1,4) = GOOD

Good -

Column_name LIKE GOOD%

15. Create indexes on foreign key columns if the queries always retrieve

master-detail relationship-based rows.

16. Where ever possible replace the view with the view definition if the tables

in the view are being used in the actual query.

17. Dont use hints and never inside or on views as this will not allow the system

to improve is in future a better execution path comes up.


3/4

18. When doing join of three or more tables, try to structure the query to do the

greatest elimination on the first join. This can often be done by incorporating

all of the restrictive where clause conditions on one table. The result is asmaller driving set.

19. For very large tables , consider taking advantage of table and indexpartitioning.

20. If possible, write SQL statements in such a way that sorting is not needed.

Several SQL language components cause implicit sorts , such as DISTINCT,

GROUP BY, UNION, MINUS and INTERSECT.

21. Sorts can be avoided by creating indexes. If possible create index on ORDER

BY columns this should be the last option as a solution.

22. If you have a non-equijoin , a nested loops is the only possible join

operation. It is possible that the outer table is accessed with full table scan

23. Consider to create function based indexes statements that containexpressions in the WHERE clauses.

24. Use histograms for a column when the data is highly skewed.

25. Avoid using histograms when columns is not used inwhereclause, the

column is unique and used only with equality predicates, all predicates on thecolumn use bind variables , the column data is uniformly distributed.

26. Experiment with redundantjoins. For example, if you join three tables, two

joins are adequate. Adding a third may give the optimizer more options.

27. Is there any unnecessary or redundant action? Are DISTINCT and UNIONoverused? Do you see HAVING used like WHERE?

28. To improve SQL efficiency, useequijoins whenever possible.

29.Tweek the Where clause to get the job of ORDER BY

Bad -select * from address order by city

Good -

select * from address where city >

30. Consider EXISTS in place ofDISTINCT, avoid joins that use DISTINCT, use

EXISTS subquery instead

Bad -select distinct deptno, deptname from emp, dept where

emp. deptno = dept. deptno


4/4

Good select deptno, deptname from dept where

exists (select X from emp whereemp. deptno = dept. deptno).

31. Order Table in the FROM Clause , its important under rule based optimizer,

and won't hurt under cost based optimizer . Order FROM clauses indescending order of table sizes based upon row counts

select * from larger table, smaller tableselect * from larger table, smaller table, smallest table

select * from larger table, smaller table, associative table.

performance tuning guidelines

Documents