Code Review guidelines:

MUST DO’s during a code review :

1. Get an Explain Plan and study all cursors and sql’s.

2. Don’t consider the current elapsed time as a measure of performance because

the code review is done on development database and the data volume in it is not
realistic 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 <= one date
5. Try to avoid using functions on indexed columns.

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

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

8. Consider bitmap indexes when where clause predicate contain low-

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

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

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 where
not exists (select ‘X’ from dept where
deptstatus = ‘A’ and
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. Don’t 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.
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 a
smaller driving set.

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

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 contain
expressions 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 in where clause, the
column is unique and used only with equality predicates, all predicates on the
column use bind variables , the column data is uniformly distributed.

26. Experiment with redundant joins. 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 UNION
overused? Do you see HAVING used like WHERE?

28. To improve SQL efficiency, use equijoins 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 of DISTINCT, avoid joins that use DISTINCT, use
EXISTS sub- query instead

Bad -
select distinct deptno, deptname from emp, dept where
emp. deptno = dept. deptno
Good –
select deptno, deptname from dept where
exists (select ‘X’ from emp where
emp. 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 in
descending order of table sizes based upon row counts

select * from larger table, smaller table

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