ORACLE SQL TUNING:Check the SQL execute statement • As a rule of thumb, tables should be joined from smallest

effective number rows to largest effective number of rows For Eg, Suppose that there are 10 departments and 1000 employees, and that the inner table in each query has an index on the join column. In the first query, the first table produces 10 qualifying rows (in this case, the whole table). In the second query, the first table produces 1000 qualifying rows. If in the join order we have the first query will access the EMP table 10 times and scan the DEPT table once. The second query will scan the EMP table once but will access the DEPT table 1000 times. Therefore the first query will perform much better • We can avoid Transformed Columns in the WHERE Clause. e.g., substr, trunc etc. Do not use SQL functions in predicate clauses or WHERE clauses. Any expression using a column, such as a function having the column as its argument, causes the optimizer to ignore the possibility of using an index on that column, even a unique index, unless there is a function-based index defined that can be used. • I would avoid the LIKE predicate = Always replace a "like" with an equality, when appropriate. • I would avoid mixing data types - If a WHERE clause column predicate is numeric, do not to use quotes. For char index columns, always use quotes. There are mixed data type predicates. • To improve SQL efficiency, use equijoins whenever possible. Statements that perform equijoins on untransformed column values are the easiest to tune, e.g. using Predicates AND and =. • Would like to avoid correlated subquery by replacing with join (Inline view), as join will work faster than correlated query. • Union All will work faster than Union, and if we don’t care about the redundant data. • Proper use of table aliases when referencing columns. • Rewrite complex subqueries with temporary tables • I will make use of SQL analytic functions - The Oracle analytic functions can do multiple aggregations (e.g. rollup by cube) with a single pass through the tables, making them very fast for reporting SQL. • Consider the alternative EXISTS, IN and table joins when doing multiple table joins. None of these are consistently faster; it depends on your data. In general, if the selective predicate is in the subquery, then use IN. If the selective predicate is in the parent query, then use EXISTS. (A predicate is the syntax used to specify a subset of rows to be returned. Predicates are specified in the WHERE clause of a SQL statement.) Oracle Optimizer The optimizer is the part of the Oracle Server that creates the execution plan for a SQL statement. An execution plan is a series of operations that are performed to execute the statement. The optimizer uses various pieces of information to determine the best path: • Hints supplied by the developer • Statistics • Information in the dictionary • WHERE clause The optimizer usually works in the background. However, with diagnostic tools such as EXPLAIN and SQL*Plus AUTOTRACE, you can see the decisions that the optimizer makes. The optimizer determines the least-cost plan (most efficient way) to execute a SQL statement after considering many factors related to the objects referenced and the conditions specified in the query. This

determination is an important step in the processing of any SQL statement and can greatly affect execution time. The factors considered by the optimizer are: • Access path • Join order • Join method Access paths • • • • • Join order A join order is the order in which different join items (such as tables) are accessed and joined together. Join Methods The different join methods considered by the optimizer are: • Nested-loop join • Hash join • Sort-merge join • Cartesian join Using hints to tune Oracle SQL Among the most common tools for tuning SQL statements are hints. A hint is a directive that is added to the SQL statement to modify the access path for a SQL query.

Full-table scans Row ID scans Index scans Cluster scans Hash scans

Self-order the table joins - If you find that Oracle is joining the tables together in a sub-optimal order, you can use the ORDERED hint to force the tables to be joined in the order that they appear in the FROM clause.

Try a first_rows_n hint. Oracle has two cost-based optimizer modes, first_rows_n and all_rows. The first_rows mode will execute to begin returning rows as soon as possible, whereas the all_rows mode is designed to optimize the resources on the entire query before returning rows. SELECT /*+ first_rows */

Sign up to vote on this title
UsefulNot useful