Disclaimer

Wednesday 23 February 2022

Oracle SQL Tuning 2

 

Oracle SQL Tuning - WHERE Clause:

Beware of WHERE clauses which do not use indexes at all. Even if there is an index over a column that is referenced by a WHERE clause included in this section, Oracle will ignore the index. All of WHERE clauses can be re-written to use an index while returning the same values. In other words, don't perform operations on database objects referenced in the WHERE clause.

SELECT account_name, trans_date, amount
WHERE SUBSTR (account_name,1,7) = 'CAPITAL';   

SELECT account_name, trans_date, amount
WHERE account_name LIKE 'CAPITAL%';

SELECT account_name, trans_date, amount
WHERE account_name || account_type = 'AMEXA';   

SELECT account_name, trans_date, amount
WHERE account_name = 'AMEX'
AND account_type = 'A';

SELECT account_name, trans_date, amount
WHERE TRUNC (trans_date) = TRUNC ( SYSDATE );   

SELECT account_name, trans_date, amount
WHERE trans_date BETWEEN TRUNC ( SYSDATE ) AND TRUNC ( SYSDATE ) + .99999;

SELECT account_name, trans_date, amount
WHERE account_name = NVL ( :acc_name, account_name);   

SELECT account_name, trans_date, amount
WHERE account_name LIKE NVL ( :acc_name, '%');

SELECT account_name, trans_date, amount
WHERE amount + 3000 < 5000;   

SELECT account_name, trans_date, amount
WHERE amount != 0;   

SELECT account_name, trans_date, amount
WHERE amount < 2000;

SELECT account_name, trans_date, amount
WHERE amount > 0;

SELECT account_name, trans_date, amount
WHERE amount NOT = 0;   

SELECT account_name, trans_date, amount
FROM TRANSACTION
WHERE amount > 0;  

>>Oracle SQL Tuning - Tuning the views:

Don't forget to tune views. Views are SELECT statements and can be tuned in just the same way as any other type of SELECT statement can be. All tuning applicable to any SQL statement are equally applicable to views.

 

 

>>Oracle SQL Tuning - HAVING Clause:

Avoid including a HAVING clause in SELECT statements. The HAVING clause filters selected rows only after all rows have been fetched. Using a WHERE clause helps reduce overheads in sorting, summing, etc. HAVING clauses should only be used when columns with summary operations applied to them are restricted by the clause.

Using HAVING Clause

Not Using HAVING Clause

SELECT region, AVG (loc_size)
FROM location
GROUP BY region
HAVING region != ' SYDNEY '
AND region != ' PERTH ';   

SELECT region, AVG (loc_size)
FROM location
WHERE region != ' SYDNEY '
AND region != ' PERTH ';
GROUP BY region;

 

>>Oracle SQL Tuning - Table Lookups:

Minimize the number of table lookups (subquery blocks) in queries, particularly if your statements include subquery SELECTs or multicolumn UPDATEs.

Separate Subqueries

Combined Subqueries

SELECT emp_name
FROM emp
WHERE emp_cat = ( SELECT MAX (category)
FROM emp_categories)
AND emp_range = ( SELECT MAX (sal_range)
FROM emp_categories)
AND emp_dept = 0020;

SELECT emp_name
FROM emp
WHERE (emp_cat, sal_range)
= ( SELECT MAX (category), MAX (sal_range)
FROM emp_categories)
AND emp_dept = 0020;

 

 

 

 

 

 

 

>>Oracle SQL Tuning - Multiple Table Joins:

Consider the alternatives like EXISTS, IN and table joins when doing multiple table joins. None of these are consistently faster; it depends on your data. If there is a poor performer here, it's likely the IN clause. This query returns the employee names from each department in department category 'A'.

EXISTS

IN

Table Joins

SELECT emp_name
FROM emp E
WHERE EXISTS (
SELECT 'X' FROM dept
WHERE dept_no = E.dept_no
AND dept_cat = 'A');

SELECT emp_name
FROM emp E
WHERE dept_no IN
( SELECT dept_no FROM dept
WHERE dept_no = E.dept_no
AND dept_cat = 'A');

SELECT emp_name
FROM dept D, emp E
WHERE E.dept_no = D.dept_no
AND D.dept_cat = 'A';

>>Oracle SQL Tuning - DISTINCT vs. EXISTS:

Avoid joins that require the DISTINCT qualifier on the SELECT list in queries which are used to determine information at the owner end of a one-to-many relationship. The DISTINCT operator causes Oracle to fetch all rows satisfying the table join and then sort and filter out duplicate values. EXISTS is a faster alternative, because the Oracle optimizer realizes when the subquery has been satisfied once, there is no need to proceed further and the next matching row can be fetched.
Below query returns all department numbers and names which have at least one employee.

SELECT DISTINCT dept_no, dept_name
FROM dept D,
emp E
WHERE D.dept_no = E.dept_no;    SELECT dept_no, dept_name
FROM dept D
WHERE EXISTS (
SELECT 'X'
FROM emp E
WHERE E.dept_no = D.dept_no);

 

 

 

 

 

>>Oracle SQL Tuning - UNION ALL:

Consider whether a UNION ALL will be adequate in place of a UNION . The UNION clause forces all rows returned by each portion of the UNION to be sorted and merged and duplicate to be filtered before the first row is returned. A UNION ALL simply returns all rows including duplicates and does not have to perform any sort, merge or filter. If your tables include no duplicate records, or you don't care if duplicates are returned, the UNION ALL is much more efficient.

UNION

UNION ALL

SELECT acct_num, balance_amt
FROM debit_transactions
WHERE tran_date = '31-DEC-95'
UNION
SELECT acct_num, balance_amt
FROM credit_transactions
WHERE tran_date = '31-DEC-95';  

SELECT acct_num, balance_amt
FROM debit_transactions
WHERE tran_date = '31-DEC-95'
UNION ALL
SELECT acct_num, balance_amt
FROM credit_transactions
WHERE tran_date = '31-DEC-95';

>>Oracle SQL Tuning - DECODE:

Consider using DECODE to avoid having to scan the same rows repetitively or join the same table repetitively. DECODE is not necessarily faster as it depends on your data and the complexity of the resulting query. Also, using DECODE requires you to change your code when new values are allowed in the field.

SELECT COUNT (*)
FROM emp
WHERE status = 'Y'
AND emp_name LIKE 'SMITH%';

SELECT COUNT (*)
FROM emp
WHERE status = 'N'
AND emp_name LIKE 'SMITH%';
SELECT COUNT ( DECODE (status, 'Y', 'X', NULL )) Y_count,
COUNT ( DECODE (status, 'N', 'X', NULL )) N_count
FROM emp
WHERE emp_name LIKE 'SMITH%';

 

 

 

 

 

>>Oracle SQL Tuning - Casting:

Oracle automatically performs casting or simple column type conversions when it compares columns of different types. Depending on the type of conversion, indexes may not be used. Make sure you declare your program variables as the same type as your Oracle columns, if the type is supported in the programming language you are using.

 
















 

 

 

 

 

 

 

 

 

 

 

 

No comments:

Post a Comment

100 Oracle DBA Interview Questions and Answers

  Here are 100 tricky interview questions tailored for a Senior Oracle DBA role. These questions span a wide range of topics, including perf...