SQL Tuning Tips and Tricks - Oracle Database

 

SQL Tuning Tips and Tricks

To increase all Database Performance, you should tune both database and SQL statements.

 There are lots of tips and tricks for SQL Tuning but they may not work under every circumstance.

 These tips and tricks are a reference while fixing performance problems in the Oracle Database.

 

1- Run TOP SQL Statements according to your Workload status.

You should know or find busy and free time of database.

Small transactions can run every time in the OLTP database, but Batch jobs or TOP SQL statements like ETL, Reporting and etc should not run every time.

If you run TOP SQL statements like ETL, Reporting and etc, then you should set available time of database for this task.

If your database load is low in the daylight, you can run it. if database is very busy, you may run it at night or weekend.

2- Make sure that CBO ( Cost based Optimizer ) statistics are correct

Statistic of Database and its objects should be up to date in Oracle database for Oracle optimizer. Because Oracle optimizer uses database statistics to generate lots of execution plans in same time and If statistics are up to date ,then Optimizer decide correct execution plans.

 If your database statistics are staled ( out of date ), then you should update it. 

3- Check and Monitor Optimizer_Mode parameters

The default value of optimizer_mode parameter is ALL_ROWS which gives better throughput, but sometimes your application or software needs FIRST_ROWS if the response time is important.

Make sure that your software or application is running very well if the optimizer_mode is FIRST_ROWS.

4- Cursor Sharing and Bind Variable

You should set CURSOR_SHARING ( default value is Exact ) parameter value according to your database and software. If related application is not used Bind Variable , response time low due to a very high number of library cache misses and lots of SQL Statements matches with the text of SQL except the literal, then you should use CURSOR_SHARING=FORCE. 

Actually Cursor_sharing= force is temporary solution, Permanent solution is to use Bind Variable.

 

Oracle doesn’t recommend CURSOR_SHARING=FORCE in the DSS(Decision support system) environment or if you are using complex queries

 

 5-Index Usage

The usage of Index is very common especially in the performance tuning of Oracle Databases. It is one of the most important objects that are indispensable and proper performance tuning of databases.

You should use an index if less than 5% of the data needs to be accessed from a data set.

If your tables are getting extremely DML, you should not use so many Index on this table. Sometimes Dropping index will provide us extra performance.

Use function-based indexes If queries contain a built-in function like to_char, decode, substr, etc. If you don’t use function-based indexes, SQL query may cause a full-table scan instead of Index scan.

 

If query contains WHERE lower(FIRST_NAME) statement, then index should be created as follows.

SELECT * FROM HR.EMPLOYEES WHERE lower(FIRST_NAME)='Donald';

CREATE INDEX EMPLOYEE_X2 ON HR.EMPLOYEES(LOWER(FIRST_NAME)) TABLESPACE HR_INDEX;

6- Materialized views usage

Materialized views is used to pre-sort sets, pre-summarize complex data warehouse information , pre-join tables and create complex objects conflicts dynamically with the demand for sub-second response time.

7- Remove Subqueries

You may remove subqueries (exists, in, not in) in the Complex queries and rewrite and use Join instead of subquery for faster performance.

8- Use Stored Procedure instead of Views

You should encapsulate the complex SQL inside a stored procedure instead of view usage. Because views are caused Unnecessary overhead and Excessive hard parsing problems.

9- Prefer uncomplicated SQL

it is not recommended to use complex SQL and subqueries. You should use WITH clause and Global temporary tables to divide and flatten-out queries.

Decomposing a query into multiple queries are better than a Complex query.

10- Use Union all instead of Union

If using union all is possible, you should prefer it instead of union, because Union are doing expensive sort to remove duplicate rows.

You should prefer uncomplicated ( Basic ) SQL instead of very complex SQL, If you cannot divide it, then You can make a very complex statement slightly less complex by using the UNION ALL operator

11- Avoid Having clause usage

Using Having clause is very expensive for the Performance tuning. You should prefer With clause instead of Having to decompose a complex query.

12- Avoid Function usage like Substr

Try to avoid using too many functions, especially don’t  use SUBSTRING, instead use LIKE clause.

Difference between substr and like is Such as “where name like ‘DEV%”;” will use an index whereas a substr such as “where substr(name,1,2) = ‘Dev’; will require a function-based index (and extended optimizer statistics) for optimal performance.

Using the substr clause is best for large production queries, when you provide a function-based index and deploy extended optimizer statistics on the target column.

 

13- Use Truncate instead of Delete

You should prefer truncate table instead of delete table if you delete too many rows on a table. Too many delete operations cause fragmentation and performance problems.

 

14- Avoid Using Triggers

You should avoid using of TRIGGERS. Just use it as a last resort. It is better to use CONSTRAINT and STORED PROCEDURE to maintain the integrity of your databases.

15- Use Bulk DML instead of Single DML

You should use Bulk Insert,Delete and Update instead of Single Insert,Delete and Update if you are executing Bulk operation.

Bulk insert,Delete and Update will give your system a huge performance boost.

16- Avoid unnecessary columns

Unnecessary columns in Select clause incur more I/O on the database and increase network traffic.

You should analyze all columns in select or DML clause and if it is unnecessary, you should remove that columns in queries. Mostly Using SELECT * is not true for database and related query performance.

17- Avoid Distinct clause

DISTINCT operator causes sorting which slows down the SQL execution time.

If it is possible, it is better that remove Distinct clause in Select.

18- Use MINUS instead of EXISTS

Minus operator is mostly running in a faster execution plan than NOT IN and NOT Exists operator.

19- Use Alias for table column

If you use more than one table in a query, you should use table aliases for column to avoid confusion.

 

 

20- Use Parallel hint for large data access

If you execute any SQL which is accessing large data sets, then you may use Parallel hint to perform it in parallel.

When you use parallel hint, you should check operating system CPU counts and cores to specify how many parallel will you use it.

If lots of people use parallel hint everytime, operating system and database can  slow down or power off because of CPU bootleneck.

21- Use COUNT(1) instead of COUNT(*)

Using COUNT(1) instead of COUNT(*) is recommended  for SQL query performance optimization

22- Use Partitioning for Large Tables

If Slow query contains large tables, then you can use table partitioning to make faster query.

23- Use CASE statements instead of DECODE

You can use CASE statements instead of DECODE for the readability and performance of the query

 

24– Use IN instead of OR

You should use IN instead of OR in the where clause. IN is used for selective predicate is in the sub query,and EXISTS is used for selective predicate is in the parent query.

 

 

 

25– Avoid Complex expressions in SQL

You should avoid using complex expression in SQL to prevent the optimizer from assigning valid cardinality or selectivity estimates.

 

--Do not use:
WHERE SUBSTR(a.id, INSTR(b.id, ',') - 1) = SUBSTR(b.id, INSTR(b.id, ',') - 1)

--Use this instead of above:
WHERE a.id = b.id



--Avoid:
WHERE id = NVL(:a1, id)

WHERE NVL(id,-1) = ( 1, etc...)

NVL (col1,-999) = ….


TO_DATE(), TO_NUMBER(), and so on

26– Prefer INNER JOIN instead of OUTER JOIN

Inner join is recommended instead of Outer Join if possible. Because Outer join limits the database optimization options

27– Avoid ORDER BY and GROUP BY If possible

it is recommended to avoid ORDER BY, GROUP BY clause , if using ORDER BY, GROUP BY clause is not mandatory for you. Because ORDER BY, GROUP BY causes sorting and result in one of the most expensive operations in SQL execution.

28– Avoid Hint usage

Hint usage is not recommended instead optimizing your code.

Hint usage is the last thing you should consider for Performance tuning or it is a temporary solution.

29– Drop Unused Index

You should drop unused index on tables, monitor all indexes and check them if they are unnecessary and unused, you should drop them.

Most common mistake is using Index, Index is not good everytime. You should monitor it, If it is good for performance, you can keep it, if not you should drop it.

30– Avoid using wildcard (%)

Using wildcard (%) at the beginning of a predicate is a known performance problem in all databases.

Wildcard (%) usage LIKE ‘%abc’ causes full table scan, so avoid Using wildcard (%).

31–  Use Hash Join for Large tables Join

You should examine execution plan carefully, If 2 large tables are joined, If they don’t use Hash Join, use Hash Join hint. If a large table is joined with a small table,  If they don’t use Nested loop Join, use Nested loop Join hint.