The document discusses how Oracle's query optimizer works and provides tips for writing optimized SQL queries. It covers the rule-based versus cost-based optimizers, common problems like incorrect driving tables, issues with indexes like low cardinality fields, and how to check index selectivity. The document advises analyzing table statistics, writing queries to leverage indexes, avoiding functions in where clauses, and testing on real data rather than execution plan estimates.

1. How Oracle Query
Works ?!
Or how write most optimized query !
MohamadReza NamaziZade

2. Content
• The SQL Optimizers
• Rule-Based & Cost-Based Optimizer Problems and Solutions
• SQL Tuning Tips
• How good is the index?
• SQL Hint
• Execution plans
• Different types of index scan
• How write nice queries
• How optimized my high inefficient queries
• Conclusion

3. The SQL Optimizers
• There are 2 primary optimizer
• 1 - Rule Based Optimizer
• The rule-based optimizer (RBO) uses a predefined set of precedence
rules to figure out which path it will use to access the database.
• 2 - Cost Based Optimizer
• The cost-based optimizer uses database information such as table
size, number of rows, key spread, and so forth, rather than rigid
rules.
• Which one used on my query ?!
• OPTIMIZER_MODE = RULE - > init.ora
• OPTIMIZER_MODE = CHOOSE - > init.ora
• ALTER SESSION SET OPTIMIZER_MODE = RULE
• SELECT /*+ RULE */

4. One or more I/Os to find or
store the key value in the
index
Another I/O to read or
write the row in the table
or cluster
Golden Rules of Rule Based :
Rank Condition
1 ROWID = constant
2 Cluster join with unique or primary key = constant
3 Hash cluster key with unique or primary key = constant
4 Entire Unique concatenated index = constant
5 Unique indexed column = constant
6 Entire cluster key = corresponding cluster key of another table in the
same cluster
7 Hash cluster key = constant
8 Entire cluster key = constant
9 Entire non-UNIQUE CONCATENATED index = constant
10 Non-UNIQUE index merge
11 Entire concatenated index = lower bound
12 Most leading column(s) of concatenated index = constant

5. Golden Rules of Rule Based 2 :
RANK Condition
13 Indexed column between low value and high value or indexed column
LIKE "ABC%"
(bounded range)
14 Non-UNIQUE indexed column between low value and high value or
indexed column like
`ABC%' (bounded range)
15 UNIQUE indexed column or constant (unbounded range)
16 Non-UNIQUE indexed column or constant (unbounded range)
17 Equality on non-indexed = column or constant (sort/merge join)
18 MAX or MIN of single indexed columns
19 ORDER BY entire index
20 Full table scans

6. Why CBO over RBO ?
• RBO :
• When using the Rule Based Optimizer -- the placement of
tables in the FROM clause is relevant. We process the from
clause from the RIGHT to the LEFT -- we would tend to pick a
driving table from the end of the FROM list. There is a hint in
the Cost Based Optimizer to have this happen as well.
• CBO :
• When using CBO -- the order of tables is not relevant (unless
you hint it to be). We use the statistics and data dictionary to
determine which table is best to be used as the driving table.
• Ask TOM

7. Why CBO over RBO 2…
What’s wrong with RBO ?
Incorrect driving table (example above)
Incorrect index
Incorrect driving index
Using the ORDER BY index and not the WHERE index

8. CBO problems !?
• The skewness problem
• SELECT * FROM at_tri_payment_way t where t.paymnt_status
= 'PAID'
• (1 – PAID = 5,000,000, 2 - UNPAID = 100)
• unaware of how many rows exist for each of 1 & 2
• assumes a 50/50 spread of data for each
• Solution :
• ANALYZE TABLE TRANS COMPUTE STATISTICS FOR ALL
INDEXED COLUMNS

9. Common Problems …
• 1. Statement not written for indexes
• 2. Indexes are missing or inappropriate
• 3. Use of single-column index merge
• 4. Misuse of nested loop, sort merge, or hash join
• 5. Misuse of IN, EXISTS, NOT IN, NOT EXISTS, or table joins
• 6. Unnecessary Sorts
• 7. Too many indexes on a table
• 8. Use of OR instead of UNION
• 9. Tables and indexes with many deletes

10. Statement not written for indexes
• Use function : substr , trunc, NVL…
• User != <> NOT : indexes can tell you what is in a table but not
what is not in a table !!!
• String concentration ||
• Arithmetic

11. Leading Column
• On Partitioned tables
• Column on which partition created must be on where clause
• Must be first on Multi-Column Index
• On Composite Index
• Must be specified in condition

12. How good is the index?
• unique index values
• selectivity = ----------------------------
• total number records
• low cardinality fields make bad indexes
• Gender(male, female)
• primary key is highly selective(100% selective)
• If there are 1000 rows, there will be 1000 unique keys

13. Conclusion
• B-tree indexes are created to decrease the amount of I/O
required to find and load a set of data. A highly selective index
uses least amount of I/O necessary, poorly selective indices
are not much better than a table scan.
• Always decide on real data and don’t stick with execution plan
numbers .